Fault tolerant battery management system

Abstract

The present invention relates to a fault tolerant battery management system to enable a battery system to overcome a single point of failure in its control system and to deliver charge stably by redundancy implementation. The battery management system has redundant hardware devices including a plurality of microcontrollers (MCUs) connected to a plurality of controller area network (CAN) buses. The active MCU periodically checks health information from the standby MCU.

Description

Technical Field

[0001] The present invention relates to a battery, and more particularly to a battery controller. Background Art

[0002] Battery usage is becoming more and more common and prevalent in all applications. As battery usage pervades all different parts of daily life, interruptions in power delivery from such batteries begin to become a problem in the lives of those who rely on these batteries.

[0003] The present invention provides a solution to mitigate the effects of sudden battery unavailability. Summary of the invention

[0004] In one embodiment, the present invention is a fault-tolerant battery management system with multiple battery cells. The fault-tolerant battery management system includes multiple application front-end (AFE) devices, multiple fuel gauges connected to the AFE devices, and multiple microcontroller units (MCUs) connected to the fuel gauges. Each AFE device is connected to multiple battery cells, a first AFE device among the multiple AFE devices is in active mode, and a second AFE device among the multiple AFE devices is in standby mode. Each fuel gauge is connected to both the first AFE device and the second AFE device, a first fuel gauge among the multiple fuel gauges is in active mode, and a second fuel gauge among the multiple fuel gauges is in standby mode. Each MCU is connected to both the first fuel gauge and the second fuel gauge, a first MCU among the multiple MCUs is in active mode, and a second MCU among the multiple MCUs is in standby mode. Both MCUs are connected to a communication bus, and each MCU is assigned an identification (ID) number, wherein, when the fault-tolerant battery management system is started, each MCU undergoes a self-test and assigns the healthy MCU with the lowest ID number to be in active mode.

[0005] In another embodiment, the present invention is a fault-tolerant battery management system, which further includes a plurality of controller area network (CAN) buses to which the plurality of MCUs are connected.

[0006] In yet another embodiment, the present invention is a fault tolerant battery management system having an active MCU that periodically broadcasts a message onto a CAN bus to indicate that the active MCU is a healthy one.

[0007] Therefore, the present systems and methods are advantageous because they enable stable delivery of charge through a battery.Other advantages and features of the present invention will become apparent upon review of the brief description of the drawings, detailed description of the invention, and claims set forth below. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] Features and advantages of embodiments of the present invention will become apparent as the following detailed description proceeds, with reference to the accompanying drawings, in which like reference numerals depict like elements, and in which:

[0009] Figure 1 A schematic diagram 100 for a battery management system is depicted;

[0010] Figure 2 is a flow chart depicting an initialization process for a battery management system;

[0011] Figure 3 is a flow chart for the operation of the standby MCU;

[0012] Figure 4 is a flow chart for the operation of an active MCU; and

[0013] Figure 5 is a flow chart for determining which MCU is the active MCU. DETAILED DESCRIPTION

[0014] In this description, the term "application" as used herein is intended to encompass executable and non-executable software files, raw data, aggregated data, patches, and other code segments. The term "exemplary" is meant only as an example and does not indicate any preference for the described embodiments or elements. In addition, the same figure numbers refer to the same elements throughout the several views, and the articles "a", "an" and "the" include plural references unless otherwise specified in the description. The terms lithium-based battery, lithium-ion battery, lithium-iron-phosphate battery, and lithium battery are used interchangeably, and "battery" and "battery pack" are used interchangeably. Lithium batteries in this specification refer to any type of lithium battery. Standby mode and sleep mode are used interchangeably.

[0015] In the overview, the present invention provides a system and method for enabling a battery system to overcome single point failures in its control system and stably deliver charge through redundant implementation. The system of the present invention is not only applicable to lithium battery systems, but also to lead-acid battery systems and all other battery systems. The system of the present invention provides a battery system with an active-standby topology that prevents power outages when components fail. For certain components in the battery management system, two sets of devices are provided. One device is designated as an active device and the other device is designated as a standby device. For example, when there are two controllers in the system, one controller is running (active) while the other controller is in sleep mode (standby). The standby controller will periodically "wake up" to synchronize with the active controller; during this synchronization, the runtime data of the active controller is retrieved by the standby controller before the standby controller returns to sleep mode. The active controller monitors and controls the operation of the system and switches control of the system to the standby controller when the active controller is not "healthy".

[0016] Figure 1 The circuit diagram 100 of the present invention illustrates the object of the present invention with an active-standby topology. The connection circuit diagram 100 illustrates a plurality of battery cells 102 connected to a plurality of analog front end (AFE) devices 104, 106. Each of the AFEs 104, 106 detects and monitors a plurality of battery cells. The AFEs 104, 106 detect the output voltage from each battery cell 102, and if the output voltage is outside of an expected range, the AFEs 104, 106 will record the battery cell 102 as a fault in its internal register. Each of the AFEs 104, 106 is connected to two fuel gauges 108, 110. The fuel gauges 108, 110 are capable of determining the state of health of each AFE 104, 106 based on input from the AFEs. The fuel gauges 108, 110 collect data such as state of charge (SOC), state of health (SOH), and cycle life. The fuel gauges 108, 110 pass the data to a micro control unit (MCU) 128, 130. The MCU is connected to a Controller Area Network (CAN) bus, and each MCU is assigned a unique CAN bus identification number (ID).

[0017] The charging and discharging operations of the battery system are controlled by MOSFETs 112, 116, 114, 118. Two MOSFETs are connected to each MCU, one MOSFET enables current discharge when turned on, and the other MOSFET enables battery charging when turned on. The two MOSFETs 112, 116 connected to the active MCU 128 are in active mode, and the two MOSFETs 114, 118 connected to the standby MCU 130 are in standby mode. The MOSFET in standby mode will be in the off state, and the MOSFET in active mode will be in the on state.

[0018] The determination of whether to enable charging of the battery cell or whether to enable discharging from the battery cell is completed by comparing the reference voltage with the output voltage from the battery cell. The comparison is completed by comparators 120, 122, 124, 126, and the comparison result controls the MOSFET. The control of the charging mode and the discharging mode is summarized as follows. The battery cell is in the charging mode when the MOSFET 116 is turned on, and the battery cell is in the discharging mode when the MOSFET 112 is turned on. If the comparator 122 detects a voltage higher than the reference voltage, the MOSFET 116 is turned off. If the comparator 120 detects a voltage lower than the reference voltage, the MOSFET 112 is turned off. The above control operation prevents one battery management system from charging another battery management system, and vice versa. In addition to the comparison result, the operation of the MOSFET is also controlled by the MCU. When the overvoltage protection threshold voltage is reached, the charging MOSFET will be turned off from the AFE. When the undervoltage protection threshold voltage is reached, the discharging MOSFET 112 is turned off.

[0019] AFE provides 3 stages of protection to the system and each stage is defined by the level of current output. When AFE detects a fault, AFE will react depending on the state of the battery system. In the first stage, below 100A, AFE allows the battery system to continue to operate. In the second stage, for currents between 100A and 500A, the battery system will operate for 4 minutes. In the third stage, for currents over 500A, AFE allows the battery system to operate for 1 minute.

[0020] AFE 104 provides both undervoltage protection and overvoltage protection when a voltage threshold is reached. AFE 104 also provides both undervoltage release and overvoltage release when a voltage release threshold is reached. The overvoltage protection threshold is first reached, for example, 4V, and the charged MOSFET is turned off. The overvoltage release is reached, for example, 3.9V, to release the charged MOSFET back to the on state. The undervoltage protection threshold is first reached, for example, 3.0V, and the discharged MOSFET is turned off. The undervoltage release is reached, for example, 3.1V, to release the charged MOSFET back to the on state. MCU 128 also provides another layer of protection by monitoring the BMS current. The MCU specifies the current level and duration. The MCU can set multiple stages and durations to meet the requirements of different applications. For example, the MCU can enter sleep mode when the current is below 800mA for 72 hours.

[0021] MCU128, 130 executes user defined programs and provides additional protection for the battery system. When MCU 128, 130 detects a fault in the system or receives a fault indication from AFE, MCU can take different actions, such as shutting down the faulty AFE and switching AFE. Both MCU 128, 130 communicate with external devices having CAN controllers (not shown) via CAN bus, and each MCU CAN bus controller is assigned a unique identification (ID) number on the same CAN bus.

[0022] Figure 2 200 is a flowchart depicting the initialization process for a battery management system. When the battery management system is turned on, the entire system completes a hardware self-test. Check the MOSFET, step 202, if any MOSFET is bad, an alarm is sent by the controller and the switching of the MOSFET will be completed, step 208. Then check the bus connection, that is, whether the communication between the hardware components is OK, step 204. It is necessary to ensure that the MCU can communicate through the CAN bus. If either MCU cannot communicate through the CAN bus, it will switch to the other CAN bus. Both MCUs need to establish communication with the external controller for the system to operate normally. Again, if the connection bus is not OK, an alarm will be sent. Records can be made for later analysis of the system. Finally, check the MCU, step 206. Only after all components have been checked does the battery management system begin to operate normally.

[0023] Figure 3A flow chart 300 for the operation of a standby MCU is depicted. During normal operation of the battery management system, one MCU 128 is active while the other MCU 130 is standby. The standby MCU 130 is in sleep mode and wakes up periodically, step 302, and requests data from the active MCU 128, step 304. The requested data is the runtime data of the active MCU 128. The runtime data is essential if the active MCU 128 has a problem and the standby MCU 130 must take over. The standby MCU 130 checks if the runtime data is received, step 306, and if the runtime data is received, the standby MCU 130 updates its internal copy of the runtime data, step 308, and goes back to sleep mode, step 310. If no runtime data is received from the active MCU 128, this means that the active MCU 128 may have a problem, and an alarm is sent to the controller, step 314. The standby MCU 130 also records the failure to receive runtime data from the active MCU 128 in the MCU's internal flash memory so that the record can be analyzed later. The cycle repeats when the timer expires, step 312. The switching between the active MCU 128 and the standby MCU 130 is controlled by the controller. If the controller does not receive regular communication from the MCU, the system will stop.

[0024] Figure 4 4 is a flow chart 400 for the operation of the active MCU. The active MCU 128 periodically checks the standby MCU 130 by sending a message or a probe to request health information from the standby MCU 130, step 402. If the standby MCU 130 does not respond, the active MCU 128 sends an alert to the controller, step 414. If the standby MCU 130 is OK, the active MCU 128 confirms that the system is OK and sends a keep alive message to the controller, step 406. The keep alive message is a broadcast message to the CAN bus network. The battery management system continues to operate normally, step 408, and the timer periodically expires causing the active MCU 128 to check the standby MCU 130, step 412.

[0025] The procedure for checking whether the standby MCU 130 is healthy can be implemented differently. For example, the standby MCU 130 periodically requests runtime data from the active MCU 128, such as Figure 3, and this periodic check can be used as an indication of the health status of the standby MCU 130. If the standby MCU 130 fails to request a run time date at a predetermined time, the active MCU 128 can interpret this as an indication that the standby MCU 130 may be facing a problem. Communication between the active MCU and the standby MCU is first completed through the primary (active) CAN bus. If the communication fails, the same communication will be attempted through the secondary (standby) CAN bus. If the communication between the active MCU and the standby MCU cannot be established through the CAN bus or cannot be established between the MCU and the controller, the main alarm is set and the system stops.

[0026] Figure 5 5 is a flow chart 500 for determining which MCU is the active MCU during a boot procedure. When the system is booted, each MCU performs a self-test, step 502. If the self-test for the MCU is unsuccessful, step 504, an alert is sent to the controller, step 514. When the MCU self-test fails, the fault is recorded in flash memory so that it may be analyzed later. After the self-test, the MCU checks its own CAN bus ID, step 506. Each MCU is pre-assigned a CAN bus ID, and the MCU knows its hierarchy compared to other MCUs. If the MCU recognizes that it does not have a lower bus ID, step 508, the MCU will understand that it is a standby MCU, step 516. If the MCU has a lower bus ID, the MCU sets itself as the active MCU, step 510, and sends a message to the controller, step 512, notifying the controller that it is active. The active MCU 128 continues to send "keep alive" messages to the controller; the standby MCU 130 does not send such a message.

[0027] When the battery management system is in operation, high availability of the battery is made possible by several layers of redundancy. The active MCU monitors and controls the battery management system. The active MCU communicates with the active fuel gauge, which receives data from the active AFE, which monitors the battery cells.

[0028] The AFE measures the output voltage of the battery cells and has registers that record the status of each battery cell. The active MCU pulls data from the registers of the active AFE. The fuel gauge determines the state of health (SOH) of the active AFE based on the data from the AFE, and this information about the SOH is sent or pulled by the active MCU. There are two detection points for each battery cell that the active AFE can access. If the reading of the battery cell is incorrect, the register will reflect the incorrect reading, which is an indication that the AFE is not OK. When the active AFE is unhealthy, the standby AFE is made active and the previously active AFE is deactivated.

[0029] If there is a problem with the active gauge, which will prevent the active MCU from accessing the active AFE, the active gauge provides registers for the active MCU to pull and these registers will indicate whether the active is healthy. The active MCU will enable the standby gauge to become active and deactivate the previously active gauge if it is unhealthy.

[0030] Finally, when the active MCU faces a problem, it will not send a "keep alive" message to the controller. When the active MCU detects that it is unhealthy, the active MCU will notify the standby MCU to switch. The standby MCU will also pull information from the active MCU for health information. If the standby MCU does not receive health information from the active MCU, a switch of MCUs occurs. The switch event is recorded in flash memory. The controller will then make the standby MCU active and deactivate the previously active MCU.

[0031] exist Figures 2 to 5 The steps illustrated do not require or imply any particular order of actions in the context of the present invention. The actions may be performed sequentially or in parallel. The method may be implemented by executing a sequence of machine-readable instructions embedded in a memory (storage unit) of the MCU or in a controller. The instructions may reside in various types of signal-bearing or data storage media.

Claims

1. A fault-tolerant battery management system, the fault-tolerant battery management system having a plurality of battery cells, characterized in that: The fault-tolerant battery management system comprises: A plurality of application front end (AFE) devices, each AFE device connected to a plurality of battery cells, a first AFE device of the plurality of AFE devices being in an active mode, and a second AFE device of the plurality of AFE devices being in a standby mode; a plurality of fuel gauges, each fuel gauge connected to both the first AFE device and the second AFE device, a first fuel gauge of the plurality of fuel gauges being in an active mode and a second fuel gauge of the plurality of fuel gauges being in a standby mode; a plurality of microcontroller units (MCUs), each MCU being connected to both the first fuel gauge and the second fuel gauge, a first MCU of the plurality of MCUs being in an active mode, a second MCU of the plurality of MCUs being in a standby mode, both MCUs being connected to a communication bus, each MCU being assigned an identification (ID) number, When the fault-tolerant battery management system is started, each MCU undergoes a self-check and the healthy MCU with the lowest ID number is assigned to be in active mode.

2. The fault-tolerant battery management system according to claim 1, characterized in that: The fault-tolerant battery management system further includes a plurality of controller area network (CAN) buses to which the plurality of MCUs are connected.

3. The fault-tolerant battery management system according to claim 2, characterized in that: The first CAN bus is designated as active and the second CAN bus is designated as standby.

4. The fault-tolerant battery management system according to claim 3, characterized in that: The communication between the plurality of MCUs is completed through the first CAN bus, and when the first CAN bus fails, the communication between the plurality of MCUs is switched to the second CAN bus.

5. The fault-tolerant battery management system according to claim 1, characterized in that: Each MCU further includes flash memory for storing state of health information.

6. The fault-tolerant battery management system according to claim 5, characterized in that: When the MCU self-test fails, the failure of the self-test is recorded in the flash memory.

7. The fault-tolerant battery management system according to claim 1, characterized in that: When none of the plurality of MCUs can communicate with the external controller, the fault-tolerant battery management system ceases normal operation.

8. The fault-tolerant battery management system according to claim 1, characterized in that: The standby MCU periodically requests runtime data from the active MCU.

9. The fault-tolerant battery management system according to claim 1, characterized in that: The active MCU periodically requests health data from the standby MCU.

10. The fault-tolerant battery management system according to claim 1, characterized in that: The active MCU periodically broadcasts a message onto the CAN bus to indicate that the active MCU is healthy.

Images