Lithium battery system with communication control

Abstract

The application relates to the field of communication control, and particularly discloses a lithium battery system with communication control, which can autonomously determine whether a vehicle is in a dynamic running state or a static parking state by analyzing the characteristics of the working current in real time, and generate a corresponding communication configuration file. Meanwhile, the communication mode instruction from the VCU is received and analyzed. Through a priority arbitration mechanism, the communication mode finally adopted is intelligently determined: when there is no explicit instruction from the VCU, the communication frequency and data content are adjusted according to the self-sensing result; when the instruction from the VCU is received, the instruction is preferentially executed. In this way, the VCU can obtain real-time and comprehensive battery information for accurate control, thereby solving the technical problem that the static waste and dynamic demand cannot be considered in the background art.

Description

Technical Field

[0001] This application relates to the field of communication control, and more specifically, to a lithium battery system with communication control. Background Technology

[0002] With the development of new energy technologies, lithium batteries are rapidly replacing traditional lead-acid batteries in industrial vehicles such as electric forklifts due to their significant advantages such as high energy density, long lifespan, and environmental friendliness. However, most lithium battery systems on the market currently only have basic protection functions such as overcharge, over-discharge, and short circuit protection, lacking intelligent management capabilities. These systems cannot engage in deep information interaction with the vehicle control unit (VCU), resulting in the vehicle system's inability to accurately grasp key data such as the battery's real-time health status, remaining charge, and temperature. This not only affects battery efficiency and lifespan but also limits further improvements in vehicle performance. Therefore, in order to achieve refined battery management and diagnosis, developing an intelligent lithium battery system with communication control functions has become an urgent need for industry development.

[0003] To meet this demand, some lithium-ion battery systems with communication capabilities have emerged, typically establishing CAN bus communication between the Battery Management System (BMS) and the Vehicle Control Unit (VCU). However, existing communication strategies generally suffer from rigid design. For conservative reasons of safety and compatibility, communication protocols are often designed as a one-size-fits-all fixed pattern. Regardless of the vehicle's operating conditions, the BMS broadcasts a message containing all data to the bus at a fixed high frequency, based on the most demanding dynamic conditions (such as full-load acceleration). While this context-independent strategy ensures basic reliability, it introduces significant drawbacks. When the vehicle is stationary for extended periods, the BMS's continuous high-frequency communication not only causes unnecessary power consumption and exacerbates battery self-discharge but also generates a large amount of redundant data, continuously consuming CAN bus bandwidth and increasing network load. Furthermore, during dynamic vehicle operation, the fixed communication pattern cannot prioritize and transmit critical data at high frequencies based on changes in load, limiting further optimization of control performance. Ultimately, the above problems arise because most existing BMS systems are positioned as purely slave devices, lacking the ability to self-aware of the actual operating conditions of vehicles and thus unable to intelligently adjust their communication behavior.

[0004] Therefore, how to enable the BMS communication strategy to adaptively adjust according to the actual operating state of the vehicle (such as dynamic or static) to reduce power consumption and bus load when static, while ensuring high-frequency real-time transmission of critical data when dynamic, so as to comprehensively optimize system energy efficiency and communication efficiency while ensuring safety, has become a technical problem that urgently needs to be solved in this field. Summary of the Invention

[0005] To address the aforementioned technical problems, this application is proposed. According to this application, a lithium battery system with communication control includes:

[0006] The dynamic configuration file initialization module is used to perform a self-test after the BMS system is powered on and initialize the current communication configuration file to a preset dynamic configuration file after the self-test is completed. In the dynamic configuration file, the BMS system broadcasts battery status information to the CAN bus at the highest frequency and with the most complete data content.

[0007] The BMS detection module is used to perform BMS operating current characteristic analysis and operating condition self-sensing on the acquired real-time current data stream to obtain the BMS detection configuration file.

[0008] The VCU instruction receiving and parsing module is used to receive and parse the received VCU message instructions in VCU communication mode to obtain the VCU instruction configuration file.

[0009] The file priority arbitration module is used to arbitrate the communication configuration file priority of the BMS detection configuration file and the VCU instruction configuration file to obtain the final communication configuration file.

[0010] The CAN message generation module is used to assign the final communication configuration file to the current communication configuration file, and perform communication execution based on the current communication configuration file to generate a CAN message stream.

[0011] Compared with existing technologies, this application provides a lithium battery system with communication control, which proposes a control scheme that can adaptively adjust the communication strategy to solve the resource waste and efficiency bottleneck problems caused by the fixed communication strategy of existing lithium battery systems. Its core lies in endowing the Battery Management System (BMS) with self-sensing capabilities for vehicle operating conditions and responsiveness to commands from the Vehicle Control Unit (VCU). The system autonomously determines whether the vehicle is in a dynamic or static state by analyzing the characteristics of its own operating current in real time, and generates a corresponding communication configuration file. Simultaneously, the system can also receive and parse communication mode commands from the VCU. Through a priority arbitration mechanism, the system can intelligently decide the final communication mode to adopt: when there is no explicit command from the VCU, it adjusts the communication frequency and data content based on the self-sensing results; when a VCU command is received, it prioritizes the execution of that command. In this way, when the vehicle is stationary, the system can automatically switch to a low-frequency, simplified communication mode, effectively reducing power consumption and bus load; while under dynamic conditions, it switches to a high-frequency, full-data mode to ensure that the VCU can obtain real-time and comprehensive battery information for precise control, thereby solving the technical problem in the background technology that static waste and dynamic requirements cannot be met at the same time. Attached Figure Description

[0012] The above and other objects, features, and advantages of this application will become more apparent from the more detailed description of the embodiments of this application in conjunction with the accompanying drawings. The drawings are provided to further illustrate the embodiments of this application and form part of the specification. They are used together with the embodiments of this application to explain this application and do not constitute a limitation thereof. In the drawings, the same reference numerals generally represent the same components or steps.

[0013] Figure 1 This is a schematic block diagram of a lithium battery system with communication control according to an embodiment of this application.

[0014] Figure 2 This is a schematic diagram of the data flow of a lithium battery system with communication control according to an embodiment of this application.

[0015] Figure 3 This is a schematic block diagram of a BMS detection module in a lithium battery system with communication control according to an embodiment of this application.

[0016] Figure 4 This is a schematic block diagram of a VCU command receiving and parsing module in a lithium battery system with communication control according to an embodiment of this application.

[0017] Figure 5 This is a schematic diagram of the logic flow of a file priority arbitration module in a lithium battery system with communication control according to an embodiment of this application. Detailed Implementation

[0018] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0019] It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0020] To address the resource waste and efficiency bottlenecks caused by the fixed communication strategies in existing lithium battery systems, this application proposes a lithium battery system with communication control. Figure 1 This is a schematic block diagram of a lithium battery system with communication control according to an embodiment of this application. Figure 2 This is a schematic diagram of data flow in a lithium battery system with communication control according to an embodiment of this application. Specifically, as... Figure 1 and Figure 2As shown, the lithium battery system 100 with communication control according to an embodiment of this application includes: a dynamic configuration file initialization module 110, used to perform self-test after the BMS system is powered on, and initialize the current communication configuration file to a preset dynamic configuration file after the self-test is completed, wherein, in the dynamic configuration file, the BMS system broadcasts battery status information to the CAN bus at the highest frequency and with the most complete data content; a BMS detection module 120, used to perform BMS operating current characteristic analysis and operating condition self-sensing on the acquired real-time current data stream to obtain a BMS detection configuration file; a VCU instruction receiving and parsing module 130, used to receive and parse the received VCU message instructions to obtain a VCU instruction configuration file; a file priority arbitration module 140, used to perform communication configuration file priority arbitration on the BMS detection configuration file and the VCU instruction configuration file to obtain a final communication configuration file; and a CAN message generation module 150, used to assign the final communication configuration file to the current communication configuration file, and perform communication execution based on the current communication configuration file to generate a CAN message stream.

[0021] Specifically, the dynamic configuration file initialization module 110 is used to perform a self-test after the BMS system is powered on, and initialize the current communication configuration file to a preset dynamic configuration file after the self-test is completed. In this dynamic configuration file, the BMS system broadcasts battery status information to the CAN bus at the highest frequency and with the most complete data content. It is understandable that in the initial stage of powering on a vehicle or industrial equipment, the communication link between the vehicle controller (VCU) and the battery management unit (BMS) has just been established. At this time, the vehicle status is still unclear; it may be about to enter high-load dynamic operation, or it may only be a brief system wake-up. During this critical startup window, to ensure absolute safety and timely control response, the VCU must obtain the most comprehensive and real-time battery status information as soon as possible to complete necessary safety checks, system preparation, and accurate responses to subsequent driver operations. Therefore, presetting the communication mode to a maximum information mode with the highest safety level is a necessary pre-processing to ensure the reliability of system startup. By communicating immediately after the self-test passes using a preset dynamic configuration file, it can be ensured that regardless of the vehicle's subsequent intentions, the VCU can grasp all the key parameters of the battery the moment the communication is established. This provides a reliable and delay-free data foundation for all subsequent control strategies and operating condition judgments, thereby avoiding any potential risks that may be caused by incomplete information at the initial startup stage.

[0022] In detail, the dynamic profile is a set of parameters that are pre-defined and permanently stored in the BMS's non-volatile memory (e.g., flash memory). This profile defines a mode with the highest communication load, specifying all types of data the BMS needs to broadcast, the corresponding CAN message identifier (CAN ID) for each type of data, and their respective transmission cycles. For example, the dynamic profile might specify that: messages with identifier 0x101 are transmitted at a maximum frequency of 100 milliseconds, and their data field includes core dynamic data such as total voltage, total current, and state of charge (SOC); messages with identifier 0x102 are transmitted at a frequency of 250 milliseconds, containing secondary data such as highest cell voltage, lowest cell voltage, and highest temperature; and messages with identifier 0x103 are transmitted at a frequency of 1000 milliseconds, containing diagnostic data such as state of health (SOH), cycle count, and detailed fault codes. These parameter settings are determined based on an analysis of the VCU's battery data requirements under the most demanding operating conditions (such as full-load rapid acceleration and simultaneous lifting), ensuring the comprehensiveness and timeliness of the information. The current communication configuration file is a data area allocated in the random access memory (RAM) of the BMS. Its data structure is completely consistent with the dynamic configuration file. The CAN message generation module will directly use the real-time parameters in this memory area to package and send CAN messages.

[0023] When the BMS is powered on, the dynamic configuration file initialization module 110 is activated and first starts the hardware self-test program. This self-test program verifies the working status of core components such as the processor, memory, and clock, and checks whether the wiring connections of various voltage, current, and temperature sensors are normal. It also verifies whether the CAN transceiver can transmit and receive data normally. After the self-test program is completed, a self-test result status word is generated. If all tests pass, the status word is set to a success flag.

[0024] After confirming successful self-test, the initialization process officially begins. The dynamic configuration file initialization module 110 performs a memory copy operation, copying the complete contents of the dynamic configuration file, pre-stored in non-volatile memory, to the current communication configuration file data area in RAM, one by one. Taking the aforementioned dynamic configuration file as an example, this operation accurately writes a series of parameters, such as "identifier 0x101, period 100 milliseconds", "identifier 0x102, period 250 milliseconds", and "identifier 0x103, period 1000 milliseconds", into the corresponding fields of the current communication configuration file. At this point, the current communication configuration file is successfully initialized as a dynamic configuration file.

[0025] After initialization, control is transferred to the CAN message generation module. This module contains a scheduler based on a high-precision timer. The scheduler continuously reads parameters from the current communication configuration file and manages the transmission tasks of each message accordingly. For example, after starting, the scheduler sets a 100-millisecond timed transmission task for the message with identifier 0x101, a 250-millisecond timed task for the message with identifier 0x102, and so on, based on the parameters in the current communication configuration file. When the 100-millisecond timer expires, the CAN message generation module immediately collects the latest total voltage, total current, and SOC values, packages this data into an 8-byte data field according to a predetermined format, combines it with identifier 0x101 to form a complete CAN message frame, and sends it to the bus via the CAN controller. Similarly, when the 250-millisecond timer expires, it collects and sends the message with identifier 0x102. This process will continue, thus establishing a high-frequency, full-volume battery status information stream on the CAN bus in the initial stage after BMS startup, providing a solid guarantee for the safe operation of the entire vehicle system. Subsequent BMS detection modules and VCU command receiving and parsing modules will then dynamically adjust the current communication configuration file based on actual operating conditions.

[0026] Specifically, the BMS detection module 120 is used to perform BMS operating current characteristic analysis and operating condition self-sensing on the acquired real-time current data stream to obtain a BMS detection configuration file. It should be understood that after the lithium battery system completes power-on initialization and begins communication in the highest safety level dynamic mode, its core challenge is how to transition from this one-size-fits-all mode to an intelligent communication mode that matches the actual operating state of the vehicle. If the vehicle remains stationary for an extended period after startup, continuous high-frequency, full-data broadcasting will cause unnecessary power consumption and waste of bus resources. To solve this problem, it is crucial to give the Battery Management Unit (BMS) an autonomous environmental sensing capability that does not rely on vehicle controller (VCU) commands. By performing real-time analysis of the operating current, the physical quantity that most directly reflects the vehicle's activity state, the BMS can autonomously determine whether the vehicle is in high-load dynamic operation or low-power static parking. Therefore, the introduction of feature analysis and operating condition self-sensing processing of real-time current data stream is to enable the BMS to generate a communication adjustment suggestion based on its own judgment, namely the BMS detection configuration file, thereby providing a key decision basis for the subsequent adaptive adjustment of communication strategy, which is the first step in realizing the transformation from fixed communication to intelligent communication.

[0027] Figure 3 This is a schematic block diagram of a BMS detection module in a lithium battery system with communication control according to an embodiment of this application. In one exemplary embodiment, as... Figure 3The BMS detection module 120 includes: a current core index extraction unit 121, used to extract a first current core index and a second current core index from the real-time current data stream; and a working condition self-sensing decision unit 122, used to input the first current core index and the second current core index into a multi-threshold working condition self-sensing decision engine to obtain a BMS detection configuration file.

[0028] In detail, in the above implementation scheme, the BMS detection module 120 processes the data as follows: First, the current core indicator extraction unit 121 continuously acquires real-time current data streams from the high-precision current sensor built into the BMS. This sensor samples the current flowing through the battery main circuit at a fixed high frequency, for example, every 10 milliseconds, forming a continuous time series data. For effective feature analysis, this unit processes this data using a sliding time window. For example, if the number of sampling points N is set to 100, the unit caches the current data from the most recent second (100 sampling points × 10 milliseconds / sampling point), forming an analysis sample set. Based on this sample set, the current core indicator extraction unit 121 calculates two key statistical indicators. In an exemplary implementation scheme, the current core indicator extraction unit 121 is used to extract a first current core indicator and a second current core indicator from the real-time current data stream using the following formula:

[0029]

[0030]

[0031] in, This is the arithmetic mean of the real-time current data stream. This represents the current at each sampling point in the real-time current data stream. The number of sampling points. The first core indicator is current. This is the second core indicator of current. The first indicator is the first core indicator of current, which is the arithmetic mean of the absolute values ​​of the current. Its calculation formula is based on N current sampling points within the window. The absolute values ​​are summed and then divided by N. The absolute value of the current, whether discharging (positive current) or charging (negative current), indicates that the battery is in an active working state, and its energy is being transferred. This indicator mainly reflects the average intensity of battery energy exchange or the average magnitude of the load within a time window. A high value... This means the vehicle is continuously operating at high power. The second indicator is the second core current indicator. This refers to the standard deviation of the current. Its calculation first requires obtaining N original current sampling points. Arithmetic mean (including signs) Then, the sum of squares of the deviations of each sampling point from the average value is calculated, and this sum is divided by N and then squared. This indicator reflects the volatility or dispersion of the current within a time window. When a vehicle is dynamically moving, such as accelerating, decelerating, turning, or when the load increases or decreases, the torque required by its motor changes frequently, causing the battery output current to fluctuate drastically, and the current standard deviation will increase significantly. Conversely, when the vehicle is stationary or running at a constant power, the current will be very stable, and its standard deviation will approach zero. Therefore, the combination of these two core indicators can comprehensively characterize the vehicle's operating conditions from two dimensions: average load size and load fluctuation degree.

[0032] Next, the self-sensing decision unit 122 receives the first and second current core indicators calculated by the extraction unit and inputs them into a multi-threshold self-sensing decision engine. This engine is essentially a logical judgment rule based on preset thresholds. In an exemplary embodiment, the self-sensing decision unit 122 is configured to: if the first current core indicator is less than a first preset threshold and the second current core indicator is less than a second preset threshold, then the BMS detection configuration file is updated to a static configuration file; otherwise, the BMS detection configuration file is updated to a dynamic configuration file. That is, if the first current core indicator is less than the first preset threshold and the second current core indicator is less than the second preset threshold, then the vehicle is determined to be in a static operating condition. Otherwise, if either indicator exceeds its corresponding threshold, the vehicle is determined to be in a dynamic operating condition. The determination of these two preset thresholds is based on extensive real-vehicle testing and data calibration. By collecting and analyzing current data under various typical operating conditions (such as forklift stationary, constant speed unloaded driving, fully loaded lifting, rapid acceleration, etc.), the distribution range of the two core indicators under static and dynamic operating conditions can be clearly defined. For example, data analysis might reveal that when the forklift is completely stationary, its first core current indicator (primarily the minimal power consumption of the control unit) is typically below 5 amps, and its second core current indicator is below 2 amps. Therefore, the first preset threshold can be set to 5 amps, and the second preset threshold to 2 amps; these two values ​​together constitute a decision boundary distinguishing between static and dynamic conditions. Based on the decision engine's judgment, the condition self-sensing decision unit 122 generates a corresponding BMS detection configuration file. If the condition is determined to be static, a static configuration file is generated. This configuration file specifies a low-power, low-bandwidth communication mode, for example, extending the transmission period of core messages (total voltage, SOC) from 100 milliseconds to 2000 milliseconds and suspending the transmission of secondary and diagnostic messages. If the condition is determined to be dynamic, a dynamic configuration file is generated, the content of which is identical to the configuration used during system initialization, maintaining a high-frequency, full-volume communication mode.

[0033] In a specific implementation example: the forklift is parked after a fully loaded lifting operation. Within the first 1-second window after parking, the current core indicator extraction unit 121 collects 100 current sampling points. Since the vehicle is stationary, the current value... It stabilizes at around -0.3 amps (BMS itself and VCU standby power consumption). The first core current indicator is calculated. Approximately 0.3 amperes, the second core current indicator The current is approximately 0.05 amperes. The operating condition self-sensing decision unit 122 compares these two values ​​with preset thresholds (5 amperes and 2 amperes), finding that 0.3 is less than 5 and 0.05 is less than 2, thus the condition is met. Therefore, this unit generates a BMS detection configuration file, the contents of which are updated with the parameters of the static configuration file. This newly generated BMS detection configuration file will serve as the BMS's judgment on the current operating condition and will be output to the next processing module for final decision. Subsequently, the BMS detection module will continuously analyze the latest current data in a sliding window manner, constantly updating its judgment on the operating condition.

[0034] Specifically, the VCU command receiving and parsing module 130 is used to receive and parse the received VCU message commands to obtain the VCU command configuration file. Correspondingly, although the Battery Management Unit (BMS) achieves self-awareness of vehicle operating conditions by analyzing current data, this judgment is essentially passive and based on historical data inference. The BMS cannot predict the immediate intentions of the Vehicle Controller (VCU) or higher-level system states. For example, the VCU may be about to execute a power-down process requiring deep battery hibernation, or require the BMS to provide detailed internal data in response to the access of external diagnostic equipment; these are things the BMS cannot perceive based solely on current. Therefore, to establish a complete, reliable control system with master-slave collaborative capabilities, a command channel led by the VCU needs to be introduced. By establishing a process for receiving and parsing VCU message commands, the BMS can respond to authoritative commands from the vehicle's central processing unit (BMS), enabling its communication behavior to not only adapt to current operating conditions but also match the vehicle's future plans and specific needs. This ensures that the VCU has ultimate control over the BMS communication strategy at all times, thereby integrating the BMS's adaptive adjustment capabilities into a higher and more comprehensive vehicle management framework, guaranteeing the final decision-making power for control and the overall coordination of the system.

[0035] Figure 4 This is a schematic block diagram of a VCU command receiving and parsing module in a lithium battery system with communication control according to an embodiment of this application. In one exemplary embodiment, as... Figure 4The VCU instruction receiving and parsing module 130 includes: an instruction parsing unit 131, used to parse received VCU instruction messages to obtain a communication mode, the communication mode including sleep, static, dynamic, and diagnostic; a VCU instruction configuration file generation unit 132, used to generate the VCU instruction configuration file based on the communication mode, the VCU instruction configuration file being updated to a sleep configuration file, a static configuration file, a dynamic configuration file, or a diagnostic configuration file; an elapsed time calculation unit 133, used to read the current system time and calculate the time difference between it and the instruction timestamp of the VCU instruction message to obtain the elapsed time; and a time judgment unit 134, used to forcibly set the value of the VCU instruction configuration file to empty if the elapsed time exceeds a preset timeout duration.

[0036] In detail, in one exemplary embodiment, the VCU instruction receiving and parsing module 130 processes the instruction as follows: This process precisely processes a CAN message instruction issued by the VCU, specifically used to control the BMS communication mode. The VCU message instruction is a specific message predefined in the vehicle CAN communication protocol, possessing a unique CAN message identifier; for example, the protocol specifies its identifier as 0x251. The BMS's CAN controller hardware filter is configured to only receive messages with this specific identifier to reduce the load on the main processor. The data field length of this message is 8 bytes, and its internal bytes are defined as follows: the first byte (Byte0) carries the communication mode instruction code; the second to fifth bytes (Byte1-Byte4) are a 32-bit unsigned integer used to carry the timestamp of the instruction issuance, which is the number of milliseconds elapsed since the VCU was powered on; the remaining bytes (Byte5-Byte7) are reserved for future functional expansion. The correspondence between communication mode instruction codes and specific communication modes is as follows: 0x00 represents sleep mode, 0x01 represents static mode, 0x02 represents dynamic mode, and 0x03 represents diagnostic mode. Each mode corresponds to a configuration file pre-installed in the BMS's non-volatile memory. These configuration files are detailed sets of parameters defining how the BMS should perform CAN communication in that mode. The sleep configuration file defines the communication state with the lowest power consumption. Under this configuration, the BMS will stop broadcasting most battery status messages, retaining only a very long-period heartbeat message, for example, sending a message containing the most basic status (such as whether the BMS is normal) every 30 seconds, aiming to inform the VCU that it is still alive. All other communication activities are suppressed to minimize the BMS's static power consumption. The static configuration file defines a low-frequency, low-data-volume communication mode suitable for scenarios where the vehicle is stationary. It specifies that the transmission cycle of core messages with identifier 0x101 (containing total voltage, total current, and SOC) is extended from 100 milliseconds in dynamic mode to 2000 milliseconds, while secondary and diagnostic messages with identifiers 0x102 and 0x103 are completely suspended. This configuration significantly reduces bus load and BMS power consumption while ensuring that the VCU can monitor the battery's basic state at a lower frequency. The dynamic profile is completely consistent with the configuration loaded during system initialization. It defines the communication mode with the highest frequency and the most complete data volume, ensuring that the VCU can obtain the most timely battery information when the vehicle is dynamically driving or operating. The diagnostic profile is a special, high-information-density communication mode. When an external diagnostic tool is connected to the vehicle and requests in-depth battery diagnostics, the VCU instructs the BMS to enter this mode.This configuration file not only requires all standard messages to be sent at the highest frequency, but also activates a series of suppressed special messages used for engineering diagnostics, such as broadcasting the voltage values ​​of all individual cells, the precise readings of each temperature sensor, and detailed historical fault code records at a period of 200 milliseconds.

[0037] The first step is executed by the message command parsing unit 131. This unit continuously listens for data transmitted from the BMS's CAN transceiver. When a CAN message frame with the identifier 0x251 is captured by the hardware filter and confirmed as valid, its 8-byte data field is passed to the parsing unit. The unit first reads the content of the first byte. Continuing from the scenario of the previous embodiment, the forklift is stationary, and the BMS detection module 120 has determined that it should enter static mode. At this time, the VCU also decides to explicitly instruct the BMS to enter static mode based on information such as the vehicle key being off and the gear being in neutral. Therefore, the VCU constructs and sends a CAN message with the identifier 0x251 and the first byte of the data field being 0x01. After receiving this message, the message command parsing unit 131 extracts the value of the first byte as 0x01 and, by consulting the internally preset command code-mode mapping relationship, parses the value as the static communication mode. Simultaneously, this unit reads the second to fifth bytes of the message, combines them into a 32-bit unsigned integer, and obtains the instruction timestamp, for example, a value of 3,450,800 milliseconds. After parsing, the unit will output two results: static communication mode and an instruction timestamp with a value of 3,450,800.

[0038] The second step is executed by the VCU instruction configuration file generation unit 132. This unit receives the static communication mode output from the previous step and, based on the input mode name, locates and reads the corresponding preset configuration file from the BMS's non-volatile memory. In this example, it locates the storage address of the static configuration file, sets all parameters defined therein (i.e., the message period for identifier 0x101 to 2000 milliseconds), pauses the transmission of messages with identifiers 0x102 and 0x103, and completely copies them into a temporary data structure located in RAM. This temporary data structure, filled with static configuration parameters, is the VCU instruction configuration file. The output of this unit is this VCU instruction configuration file containing the specific communication parameters.

[0039] The third step is executed by the elapsed time calculation unit 133. This unit receives the instruction timestamp (3,450,800) output by the message instruction parsing unit 131 in parallel. Simultaneously, this unit can access a local system clock within the BMS that has been counting since power-on and is synchronized with or at the same rate as the VCU clock reference. At the moment of calculation, the unit reads the current value of the local system clock, for example, 3,450,920 milliseconds. Then, it performs a subtraction operation, subtracting the instruction timestamp from the current system time, i.e., 3,450,920 - 3,450,800, resulting in 120 milliseconds. This result of 120 milliseconds is the elapsed time.

[0040] The fourth step is executed by the time determination unit 134. This unit is established to ensure that the BMS will not be permanently locked in the mode set by the last instruction of the VCU after losing communication with the VCU. It is a key timeout failure safety mechanism. This unit receives two inputs: the elapsed time (20 milliseconds) calculated in the previous step and the parameters of the static mode in the VCU instruction configuration file generated by the VCU instruction configuration file generation unit 132. Internally, this unit presets a timeout duration based on the period at which the VCU sends the instruction message. For example, if the protocol requires the VCU to resend the communication mode instruction message every 1000 milliseconds, a reasonable timeout duration can be set to three times its period, i.e., 3000 milliseconds. This unit performs a simple comparison. It compares the input elapsed time of 120 milliseconds with the preset timeout duration of 3000 milliseconds. In this scenario, 120 milliseconds is much less than 3000 milliseconds, indicating that the BMS has just received a valid VCU instruction. Therefore, the time judgment unit 134's logical judgment is true; it does not modify the input VCU instruction configuration file and outputs it as is.

[0041] However, in another scenario, if the VCU stops sending command messages due to a fault or power failure, the elapsed time will continue to increase. If the BMS does not receive a new message with identifier 0x251 after 3000 milliseconds, the elapsed time calculated by the elapsed time calculation unit 133 will exceed 3000 milliseconds. At this point, the logical judgment of the time judgment unit 134 will be false. In this case, the unit will perform a forced null operation: it will ignore the contents of the input VCU command configuration file and instead generate a special value, namely null or a flag, as its output.

[0042] Ultimately, the output of the VCU instruction receiving and parsing module 130 is a dynamically changing result: during normal communication, it outputs a VCU instruction configuration file containing specific communication parameters, generated according to the latest VCU instructions; however, once the instruction communication with the VCU is interrupted for more than a preset time, its output will become an empty value.

[0043] Specifically, the file priority arbitration module 140 is used to arbitrate the communication configuration file priority of the BMS detection configuration file and the VCU instruction configuration file to obtain the final communication configuration file. It is understood that in the Battery Management Unit (BMS), two independent communication strategy decision sources currently exist in parallel: one is the self-sensing conclusion of the BMS based on real-time current analysis, reflecting objective physical conditions (BMS detection configuration file), and the other is the subjective instruction issued by the Vehicle Controller (VCU) based on the control intent at the vehicle level (VCU instruction configuration file). These two decision sources will generally remain consistent, but potential conflicts exist. For example, the BMS may determine that the vehicle is static due to stable current, but the VCU may be preparing to execute a battery equalization or diagnostic task requiring high-frequency data interaction. To avoid confusion and uncertainty in control logic under such circumstances, this application establishes a clear and unambiguous final decision-making mechanism, performs priority arbitration on the two configuration files, establishes a clear command hierarchy, and resolves any potential decision conflicts by granting VCU commands absolute priority. This ensures that the final communication behavior of the BMS is always consistent with the highest control intent of the vehicle, thereby guaranteeing the coordination, reliability, and predictability of the entire control system.

[0044] Figure 5 This is a schematic diagram illustrating the logic flow of a file priority arbitration module in a lithium battery system with communication control according to an embodiment of this application. Figure 5 As shown, in an exemplary embodiment, the file priority arbitration module 140 is configured to: if the VCU instruction configuration file is not empty, set the VCU instruction configuration file as the final communication configuration file; otherwise, set the BMS detection configuration file as the final communication configuration file.

[0045] In detail, in one exemplary implementation, the file priority arbitration module 140 processes the following: The arbitration rule of this module is preset to: VCU instructions have the highest and only priority. Specifically, the module first checks the status of the received VCU instruction configuration file. If the configuration file is not empty, i.e., it contains a specific communication mode parameter set generated by valid VCU instructions, the arbitration module will unconditionally select the VCU instruction configuration file as the final decision result. At this time, although the BMS detection configuration file is also received, its content will be completely ignored. Conversely, if the VCU instruction configuration file is empty, which usually occurs after a VCU communication timeout failure, the arbitration module's logic will switch to its backup plan, i.e., selecting the BMS detection configuration file as the final decision result.

[0046] To illustrate this process more clearly, we will build upon the scenarios of previous embodiments and present two typical operating conditions. Scenario 1: VCU command valid, vehicle-wide coordinated control. As mentioned in the previous example, the forklift is parked after operation. The BMS detection module 120 analyzes the stable, small standby current to determine that the vehicle is static. Therefore, it generates and outputs a BMS detection configuration file, containing the parameters defined in the static configuration file, such as a core message sending period of 2000 milliseconds and paused messages for other messages. Simultaneously, the VCU also determines that the vehicle has entered a parked state based on its own sensor information, such as the ignition key being closed and the parking brake being engaged. Therefore, it sends a communication mode command message (identifier 0x251, data 0x01) via the CAN bus. After successfully receiving and parsing this message, the VCU command receiving and parsing module 130, since the command is valid (i.e., no timeout), generates and outputs a VCU command configuration file. This file also contains the parameters of the static configuration file, and its status is not empty. Both configuration files arrive simultaneously at the file priority arbitration module 140. The module initiates arbitration logic, first checking the status of the VCU command configuration file. It detects that the file is not empty. Based on preset rules, the module immediately decides to copy the entire contents of the VCU instruction configuration file into the final communication configuration file. Thus, the final communication configuration file is set to static mode. In this scenario, even if the BMS's self-perception conclusion aligns with the VCU instructions, the arbitration logic ensures that the final decision originates from the VCU with the highest privileges.

[0047] The second scenario: VCU communication interruption, BMS autonomous management. For example, if the forklift's main power is unexpectedly cut off after a period of normal parking, causing the VCU to power down, or if a physical fault occurs in the CAN communication line, the VCU command receiving and parsing module 130 will no longer receive command messages with identifier 0x251. In its internal time judgment unit 134, the elapsed time will soon exceed the preset 3000 millisecond timeout period. Once the timeout occurs, the module's output will immediately switch from the VCU command configuration file containing static configuration parameters to an empty flag. At this time, the VCU command configuration file input received by the file priority arbitration module 140 becomes empty. Meanwhile, since the BMS itself is powered normally, its BMS detection module 120 continues to operate independently. Because the vehicle remains stationary, this module continuously outputs a BMS detection configuration file containing static configuration parameters. The arbitration module executes its logic again, checks the status of the VCU command configuration file, and finds it to be empty. Therefore, the logic jumps to the otherwise branch, and the module completely copies the contents of the BMS detection configuration file into the final communication configuration file. Therefore, the final communication configuration file is still set to static mode. The key to this scenario is that when the instructions from the superior VCU are lost, the BMS can seamlessly switch to an autonomous management mode that relies on its own perception, and continue to maintain an energy-saving communication state that matches the current operating conditions, rather than falling into a chaotic state with no instructions to execute or being locked in the last mode before the communication interruption.

[0048] The comparison between these two scenarios demonstrates that the file priority arbitration module 140 acts as an intelligent control transfer switch. Under normal circumstances, it ensures absolute control of the VCU; under abnormal circumstances, it smoothly transfers control to the BMS's self-aware system. Its final output communication configuration file, regardless of its source file, is a unique and explicit set of instructions.

[0049] In particular, when constructing a collaborative control system between the Battery Management Unit (BMS) and the Vehicle Control Unit (VCU), a fundamental arbitration logic is to establish the absolute authority of the VCU as the command center. However, this simple, absolute priority-based coverage strategy—unconditionally obeying any VCU command—ignores a crucial fact: the BMS is the unit closest to the physical reality of the battery, and it is the first to sense instantaneous risks at the cell level. When the VCU issues a low-frequency communication command to the BMS to enter static or sleep mode for some reason, such as to execute an economy driving mode, if the battery system experiences a sudden, massive current surge due to an external load short circuit or motor controller failure, the BMS, blindly obeying the low-frequency communication command, will fail to report this potentially fatal overcurrent event in a timely manner. This will cause the VCU to miss the optimal window for taking protective measures, potentially leading to permanent battery damage or even serious safety accidents such as thermal runaway. Therefore, the arbitration logic needs to be upgraded from simple hierarchical obedience to a dynamic decision-making mechanism capable of sensing and responding to physical risks. The introduction of risk-aware adaptive arbitration based on a dynamic intensity index for the BMS detection configuration file and VCU command configuration file aims to construct an intelligent arbitration core that prioritizes physical safety. This process quantifies the potential risk level of the current operating condition through in-depth analysis of the multidimensional characteristics of current data and dynamically adjusts the arbitration logic accordingly. This allows the BMS to have a higher arbitration weight than regular VCU commands at critical moments, enabling it to safely reject inappropriate safety commands. This transforms the BMS from a passive command receiver into a proactive risk warning sentinel, ensuring that the system's safety protection chain is closed and reinforced under any circumstances.

[0050] Based on this, in an exemplary preferred embodiment, the file priority arbitration module 140 is used to perform risk-aware adaptive arbitration based on a dynamic intensity index on the BMS detection configuration file and the VCU instruction configuration file to obtain the final communication configuration file, and is further used for:

[0051] The real-time current data stream is processed to calculate the average load and volatility to obtain the normalized mean absolute value and normalized standard deviation of the current. First, it's necessary to understand the battery's current operating state from a macroscopic perspective. Simply knowing the current magnitude is insufficient; it's also necessary to understand its average load intensity and stability over a period of time to obtain two core normalized indicators, providing a foundation for subsequent comprehensive evaluation. In practice, the real-time current data stream is processed within a sliding time window (e.g., collecting the most recent 100 current sampling points). It first calculates the normalized mean absolute value of the current using the following formula to quantify the average load level:

[0052]

[0053] in, Let N be the current at each sampling point within the window, and N be the total number of sampling points. The rated maximum continuous current of the battery, such as 250A. This is the absolute value of the normalized mean current. The absolute value of the current is used because it represents the presence of the load regardless of whether it is charging or discharging. Dividing by the rated maximum continuous current is for normalization, making it a dimensionless relative value. Simultaneously, the standard deviation of the normalized current is calculated using the following formula to quantify the load's volatility:

[0054]

[0055] in, This is the arithmetic mean of the current sampling points within the window. The larger this value, the more drastic the current fluctuation, corresponding to dynamic operating conditions such as frequent acceleration and deceleration of the vehicle. This represents the normalized standard deviation of the current.

[0056] Load impact calculations are performed on real-time current data streams to obtain the normalized maximum current change rate. Correspondingly, the mean and standard deviation are not sensitive enough to transient, short-duration impact events. For example, a severe short-circuit current lasting tens of milliseconds might be averaged out by a window of data lasting up to one second, thus failing to reflect its significant risk. Therefore, a dedicated metric is needed to capture such sudden events and obtain an indicator highly sensitive to instantaneous risk. In practice, the current core indicator extraction unit calculates the maximum current change rate between adjacent sampling points within the window and obtains the normalized maximum current change rate using the following formula:

[0057]

[0058] in, This is the sampling time interval, such as 10 milliseconds. This is a preset, critical current change rate that represents a dangerous condition, such as 1000 A / s. This value is set based on data analysis of the maximum current surge the battery can withstand and typical failure modes. The normalized maximum rate of change of current is an indicator that can instantly capture sudden jumps in current.

[0059] The dynamic intensity index is obtained by weighting and summing the normalized mean absolute value of current, the normalized standard deviation of current, and the normalized maximum rate of change of current. Next, these three independent indicators describing the operating conditions from different dimensions need to be integrated into a single quantitative value that comprehensively reflects the current dynamic intensity and risk level, facilitating clear threshold judgment and generating a final decision-making basis—the dynamic intensity index. In practice, the aforementioned three normalized indicators are weighted and summed:

[0060]

[0061] in, , and These are adjustable weighting coefficients, and the sum of the three is 1. The setting of these weights depends on the application scenario. For example, in industrial forklift applications where impact loads are common, the weighting coefficients can be adjusted. Set it to a higher value, such as 0.5, and and The values ​​were set to 0.2 and 0.3 respectively to emphasize the focus on sudden risks. This is the dynamic intensity index.

[0062] If the VCU instruction configuration file is not empty, in response to the dynamic intensity index being greater than or equal to the critical threshold, the dynamic configuration file is set as the final communication configuration file; otherwise, the VCU instruction configuration file is set as the final communication configuration file. If the VCU instruction configuration file is empty, in response to the dynamic intensity index being greater than or equal to the dynamic threshold, the dynamic configuration file is set as the final communication configuration file; otherwise, the static configuration file is set as the final communication configuration file. That is, based on the presence of VCU instructions and the risk level reflected by the DII, different decision paths are executed to achieve a balance between safety and coordination, outputting a unique final communication configuration file that best meets the current operating conditions and safety requirements. In specific implementation, the arbitration logic is divided into two cases: Case 1: The VCU instruction configuration file is not empty. In this case, the calculated... It is compared with a preset critical threshold. This threshold represents a clear physical danger boundary, for example, set to 0.8, and its value is determined by simulating extreme fault conditions such as short circuits. The response is used for identification. If If the value is greater than or equal to the critical threshold, it indicates that the BMS has detected a serious physical risk. In this case, it will ignore any instructions from the VCU and force the dynamic configuration file to be set as the final communication configuration file. Otherwise, if If the value is below the critical threshold, it indicates that the operating condition is within the safe range. In this case, the VCU instructions are followed, and the VCU instruction configuration file is set as the final communication configuration file.

[0063] Scenario 2: The VCU instruction configuration file is empty (e.g., communication timeout). In this case, the BMS enters adaptive decision-making mode and... It is compared with a preset dynamic threshold. This threshold is used to distinguish between the vehicle's dynamic and static operating conditions; for example, it is set to 0.4, and its value is determined by collecting DII data distribution of the vehicle under normal driving and stationary conditions. If If the value is greater than or equal to the dynamic threshold, the dynamic configuration file is set as the final communication configuration file; otherwise, the static configuration file is set as the final communication configuration file.

[0064] The following is a concrete example: A forklift's VCU sends a sleep command to the BMS because it has entered energy-saving mode, requesting the BMS to communicate every 30 seconds. At this time, the VCU command configuration file is updated to the sleep configuration. Normally, the forklift is stationary, and the calculated... The value is 0.1, far less than the critical threshold of 0.8, therefore the arbitration module sets the VCU's sleep profile to the final communication profile, and the BMS enters ultra-low power communication mode. Suddenly, due to external circuit damage, a severe short circuit occurs at the battery output, and the current spikes from 0 to 800 amperes within milliseconds. At this instant, The value will spike dramatically, leading to The instantaneous calculation result jumped to 1.6. The arbitration module detected this. (1.6) is much greater than the critical threshold of 0.8. At this point, even if the VCU instruction configuration file is still in a dormant configuration, the arbitration logic will force a safety override and immediately set the dynamic configuration file as the final communication configuration file. The CAN message generation module then broadcasts a message containing huge overcurrent information to the bus at a maximum frequency of 100 milliseconds, ensuring that the VCU can immediately detect the danger and perform protective actions such as cutting off the main relay, thereby effectively preventing the accident from occurring.

[0065] In other words, the arbitration logic described above ensures that regardless of the instructions from the host computer (VCU), as long as the battery's physical state exhibits high-risk characteristics, the communication system will forcibly switch to the highest speed and most detailed mode, providing the most timely decision-making basis for system protection, thereby significantly improving security. Furthermore, since the system is no longer a simple master-slave relationship but has evolved into an intelligent relationship of negotiation and supervision, the BMS, as the direct perceiver of the battery state, can influence or even change system behavior at critical moments, enhancing system robustness and significantly improving the system's adaptability to unknown and abnormal operating conditions.

[0066] Specifically, the CAN message generation module 150 is used to assign the final communication configuration file to the current communication configuration file and perform communication execution based on the current communication configuration file to generate a CAN message stream. In other words, after BMS self-sensing, VCU instruction parsing, and final priority arbitration, a unique and clear communication strategy decision final communication configuration file has been determined. However, this decision itself is only a static set of parameters; it needs to be transformed into actual communication behavior by an execution mechanism to truly affect the CAN bus. If the decision and execution are too tightly coupled, any change in upper-level logic may lead to complex modifications to the lower-level communication code, affecting its stability and reliability. Therefore, the introduction of assigning the final communication configuration file to the current communication configuration file and executing communication accordingly is to establish a stable, efficient, and decoupled execution core. This core is responsible for materializing the dynamic decisions of the upper-level modules into a CAN message stream on the physical bus in real time and accurately, completing the final link from control logic to physical signal output, ensuring the final realization of the entire adaptive communication strategy.

[0067] In detail, in an exemplary implementation, the CAN message generation module 150 processes the following: First, the role of the current communication configuration file needs to be clarified. It is a dedicated, structured data area allocated in the BMS's random access memory (RAM), and its data structure is completely consistent with all preset configuration files (dynamic, static, sleep, diagnostic). This data area is the sole direct basis for the communication behavior of the CAN message generation module's internal scheduler. Establishing such a working copy instead of directly reading the arbitration result ensures the stability and atomicity of communication execution. The upper-level decision module can update the final communication configuration file at any time, while the execution module only loads the final configuration into the current working configuration at specific, controlled moments, avoiding the reading of incomplete or inconsistent parameters during the update process. The module's execution process consists of two core actions: configuration update and message scheduling.

[0068] The first step is configuration updates. The CAN message generation module 150 continuously monitors the final communication configuration file output by the file priority arbitration module 140. Once a change in the file's content is detected, such as a change from dynamic configuration to static configuration, it immediately performs an assignment operation. This operation is a memory copy process that completely and accurately overwrites the current communication configuration file area written to RAM with all parameters from the final communication configuration file, including the identifier, transmission period, and enable status of each CAN message. This process is crucial for enabling dynamic switching of communication strategies.

[0069] The second is message scheduling and generation. This module internally runs a high-precision scheduler based on hardware timer interrupts. This scheduler is woken up at a fixed high frequency, such as every 1 millisecond, and performs the following tasks in a loop: It iterates through every message entry in the current communication configuration file. For each entry, it checks its enable flag. If the message is disabled, the scheduler skips it and processes the next entry. If the message is enabled, the scheduler further checks its transmission period and compares it with an internal timer associated with the message. If the internal timer's count has reached or exceeded the set transmission period, the scheduler triggers a transmission action and resets the internal timer; otherwise, it simply increments the timer. When a transmission action is triggered, the module calls the corresponding function to collect real-time data (such as total voltage, SOC, individual cell voltage, etc.) according to the CAN identifier defined in the message entry. This data is packaged into an 8-byte data field according to a predefined protocol format. Then, the identifier and data field are combined into a complete CAN message frame. Finally, the underlying CAN driver is called to send the message frame to the CAN bus.

[0070] Taking the embodiment scenario of this application as an example: when the output of the file priority arbitration module 140 switches from a dynamic configuration file to a static configuration file, the CAN message generation module 150 first performs a configuration update action, updating the content of the current communication configuration file to the parameters of the static mode. Specifically, for the message entry with identifier 0x101, its transmission period parameter is modified from 100 milliseconds to 2000 milliseconds; while for the message entries with identifiers 0x102 and 0x103, their enable status flag is modified from enabled to disabled.

[0071] In the subsequent message scheduling loop, when the scheduler processes the entry with identifier 0x101, it finds that its transmission period has changed to 2000 milliseconds. Therefore, it will only trigger the transmission of this message when its internal timer accumulates to 2000 milliseconds. When the scheduler processes entries with identifiers 0x102 and 0x103, it will directly read their disabled state, thus completely skipping any processing of these two messages. In this way, the message stream output to the CAN bus seamlessly switches from a high-frequency data stream containing multiple messages to a sparse data stream with an extremely low frequency containing only one core message, thereby achieving adaptive adjustment of the communication strategy.

[0072] In summary, a lithium battery system 100 with communication control based on embodiments of this application is described. To address the resource waste and efficiency bottlenecks caused by the fixed communication strategies in existing lithium battery systems, a control scheme that can adaptively adjust the communication strategy is proposed. Its core lies in endowing the Battery Management System (BMS) with self-sensing capabilities regarding vehicle operating conditions and responsiveness to commands from the Vehicle Control Unit (VCU). The system autonomously determines whether the vehicle is in a dynamic operating or static parking state by analyzing the characteristics of its own operating current in real time, and generates a corresponding communication configuration file. Simultaneously, the system can also receive and parse communication mode commands from the VCU. Through a priority arbitration mechanism, the system can intelligently decide the final communication mode to adopt: when there is no explicit command from the VCU, it adjusts the communication frequency and data content based on the self-sensing results; when a VCU command is received, it prioritizes the execution of that command. In this way, when the vehicle is stationary, the system can automatically switch to a low-frequency, simplified communication mode, effectively reducing power consumption and bus load; while under dynamic conditions, it switches to a high-frequency, full-data mode to ensure that the VCU can obtain real-time and comprehensive battery information for precise control, thereby solving the technical problem in the background technology that static waste and dynamic requirements cannot be met at the same time.

[0073] As described above, the lithium battery system 100 with communication control according to the embodiments of this application can be implemented in various wireless terminals, such as servers with lithium battery algorithms for communication control. In one possible implementation, the lithium battery system 100 with communication control according to the embodiments of this application can be integrated into the wireless terminal as a software module and / or a hardware module. For example, the lithium battery system 100 with communication control can be a software module in the operating system of the wireless terminal, or it can be an application developed for the wireless terminal; of course, the lithium battery system 100 with communication control can also be one of many hardware modules of the wireless terminal.

[0074] Alternatively, in another example, the lithium battery system 100 with communication control and the wireless terminal may also be separate devices, and the lithium battery system 100 with communication control may be connected to the wireless terminal via wired and / or wireless networks and transmit interactive information in accordance with an agreed data format.

[0075] The various embodiments of this disclosure have been described above. These descriptions are exemplary and not exhaustive, nor are they limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen to best explain the principles, practical application, or improvement of the technology in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. A lithium battery system with communication control, characterized in that, include: The dynamic configuration file initialization module is used to perform a self-test after the BMS system is powered on and initialize the current communication configuration file to a preset dynamic configuration file after the self-test is completed. In the dynamic configuration file, the BMS system broadcasts battery status information to the CAN bus at the highest frequency and with the most complete data content. The BMS detection module is used to perform BMS operating current characteristic analysis and operating condition self-sensing on the acquired real-time current data stream to obtain the BMS detection configuration file. The VCU instruction receiving and parsing module is used to receive and parse the received VCU message instructions in VCU communication mode to obtain the VCU instruction configuration file. The file priority arbitration module is used to arbitrate the communication configuration file priority of the BMS detection configuration file and the VCU instruction configuration file to obtain the final communication configuration file. The CAN message generation module is used to assign the final communication configuration file to the current communication configuration file, and perform communication execution based on the current communication configuration file to generate a CAN message stream; The BMS detection module includes: The current core indicator extraction unit is used to extract the first current core indicator and the second current core indicator from the real-time current data stream. The working condition self-sensing decision unit is used to input the first current core index and the second current core index into the multi-threshold working condition self-sensing decision engine to obtain the BMS detection configuration file. The current core indicator extraction unit is used to extract a first current core indicator and a second current core indicator from the real-time current data stream using the following formula: in, This is the arithmetic mean of the real-time current data stream. This represents the current at each sampling point in the real-time current data stream. The number of sampling points. The first core indicator is current. This is the core indicator for the second current. The self-sensing decision-making unit for operating conditions is used for: If the first current core indicator is less than the first preset threshold and the second current core indicator is less than the second preset threshold, then the BMS detection configuration file is updated to a static configuration file. Otherwise, the BMS detection configuration file is updated to a dynamic configuration file.

2. The lithium battery system with communication control according to claim 1, characterized in that, The VCU command receiving and parsing module includes: The message instruction parsing unit is used to parse the received VCU message instructions to obtain the communication mode, which includes sleep, static, dynamic and diagnostic modes. VCU instruction configuration file generation unit is used to generate the VCU instruction configuration file based on the communication mode, and the VCU instruction configuration file is updated to a hibernation configuration file, a static configuration file, a dynamic configuration file, or a diagnostic configuration file. The elapsed time calculation unit is used to read the current system time and calculate the time difference between it and the instruction timestamp of the VCU message instruction to obtain the elapsed time. The time determination unit is used to force the value of the VCU instruction configuration file to be empty if the elapsed time exceeds the preset timeout duration.

3. The lithium battery system with communication control according to claim 1, characterized in that, The file priority arbitration module is used for: If the VCU instruction configuration file is not empty, then set the VCU instruction configuration file to the final communication configuration file; Otherwise, set the BMS detection configuration file to the final communication configuration file.

Images