Development of a Lithium Battery Management System
Ian Hooper, March 2012

Introduction Lithium batteries have been a revolution in energy storage, and are found in almost every mobile phone and portable computer in the world. They have also been an enabling factor for electric vehicles, offering sufficient energy density to facilitate a driving range that covers the vast majority of road users' needs. However some care in the use of lithium batteries must be observed, as they can be permanently and irreparably damaged through either overcharging, over-discharging, or overheating. Each lithium cell is only a few volts, so in most battery systems (especially electric vehicles), many cells are used in series for higher voltage. In such instances, for complete protection it is necessary to monitor the voltage of every cell individually to ensure they all stay within safe operating voltages.

Some lithium cells

The following table summarises the safe voltages of the most common chemistries:

In all cases, batteries tend to offer the best performance when operated warm (say 30-50°C), but may be prone to damage above about 60°C. As such another beneficial safety feature is to monitor cell temperatures to ensure they stay under this temperature.

The device which performs all this monitoring is known as a Battery Management System, or BMS. There are lots of BMSs on the market (click here for a great database of them) so there's little point developing your own – unless, like me, you enjoy the creative process. This article discusses the design of a BMS which I developed for use in my Mazda RX7 conversion. Schematics, PCB files and AVR code can be found at the end for those wishing to use the design, it is provided free but without any warranty, support or guarantees! (i.e use them however you like but don't sue me..)

Design Requirements

The intended battery pack to monitor is an 88S8P arrangement (88 cells in series by 8 in parallel) of Headway 38120S cells, i.e about 300V 80Ah. The Headway cells were chosen due to their respectable power density, being about twice that of Winston (ThunderSky) or CALB (Sky Energy) cells, without being too much more expensive. I decided to go for a modular battery design consisting of blocks of 8S8P cells, with a single BMS board monitoring each block (i.e 8 voltages monitored per BMS board). The RX7 would have 11 of these modules in series. For development, however, I built an 8S1P pack of K2 26650EVs - a nice small test pack to work with on the bench (pictured below).

Some of the Headway cells for the RX7

"Here's one I prepared earlier.." Prototype BMS connected to K2 test pack

The most important function of any lithium BMS is to monitor cell voltages, and be able to act if any go out of range. For my design, I decided to go with simple voltage dividers to reduce the 0-32V range down to about 0-5V, which a microcontroller reads with its onboard 10-bit ADC. With 10-bit resolution (1024 steps), the measured resolution would be about 32mV, which seemed sufficient (though a system which reports voltages could do with higher accuracy). However an important aspect of any BMS which draws its power from the cells it's monitoring, is a low quiescent current draw, such that the BMS itself doesn't flatten the batteries if left for extended periods. Having voltage dividers permanently in-circuit seemed like a bad idea for quiescent power draw, so I added optotransistors which could switch each voltage divider on and off. These are each on for less than 1% of the time, which hugely reduces quiescent current.

As a way of signalling other systems regarding any battery errors, I went with small solid state relays. These switch with a far lower input current requirement (a couple of mA) compared with physical relays, which helps minimise BMS power consumption. I used Vishay LH1546AD devices, which only cost a few dollars each. There are three output relays: one to signal over-voltage (stop charging), one to signal under-voltage (stop driving), and one if the shunts are on (optionally, throttle back the charger for a balance charge).

Another useful feature of BMSs is pack balancing, which can compensate for slight differences in self-discharge between cells. The easy way to do this is shunt balancers, which basically bleed off some power if a cell voltage goes above a certain threshold, to stop that cell going any higher while the other cells come up to charge. Many BMS designs utilise 5W resistors to dissipate the extra energy, but for my design I used TIP102 darlington transistors straight across the cells, switched by the microcontroller via optocouplers, with a weak base turn-on to restrict current flow. The result is a few amps of shunt current, which must be dissipated into a heatsink which the transistors get attached to. In this way, I can use a much bigger heatsink (even using the vehicle chassis) to get rid of shunt energy, rather than use resistors which get hot (potentially a fire hazard).

The final safety feature of the BMS is temperature monitoring. Lithium cells can be damaged if they get too hot, so thermal protection is quite valuable. I added dual temperature sensor inputs, with one thermistor attached to the shunt heatsink, and one attached to one of the cells. It's calibrated for about 60°C - so if either cell temperature or the shunt heatsink go above this, it can stop the charger and/or motor controller.

Another component of note is the Recom R785 power supply. These are a 5V switchmode power supply which is pin-compatible with typical LM7805 linear regulators, but much more efficient. In this application efficiency of the power supply is around 90% instead of 17% for linear. Although the Recom is an expensive part (about $10 each), I figured it was worth the cost to minimise the BMS's power consumption. From tests, the BMS appears to consume under 10mA, so would take several years to flatten a typical EV battery.

Electrical Schematic

After prototyping/verifying the various systems described above on breadboard, it was time to create the schematic and PCBs. For such tasks I use Eagle, from Cadsoft. It's one of the most popular and (I believe) best free PCB programs out there, and is supported by most PCB manufacturers (so you can send them Eagle files instead of Gerber). The picture below shows the schematic I came up with. To help clarify the circuit, click here for a labelled version.

The first thing you might notice is a lot of optocouplers, two per cell in fact: one for voltage sampling, the other for enabling the shunt transistors. The top right section shows the eight transistor shunt units, and the bottom right shows the voltage samplers. The samplers are activated one at a time, so all use the same low-side resistor and feed to a single ADC input pin, which means in theory the design could be extended to a larger number of cells - though with 10-bit resolution the accuracy goes down with each cell added, so a better ADC chip may be needed.

Bottom left shows the solid state relay outputs, above that the ATmega16A microcontroller. This is a great micro with a lot of I/O pins, though the DIP40 (through hole) package is pretty huge and takes up a lot of PCB space. Top left is the power supply including capacitors and noise choke, and top middle is the temperature inputs - voltage divider plus some filtering before connecting to the AVR's ADC pins. A good rule of thumb when designing any microcontroller circuitry is to have noise filtering (chokes and/or RC filters) on every input, and buffers on every output. This prevents EMI noise from reaching the microcontroller pins and causing electrostatic damage to the microcontroller. There's a lot of info on the internet about designing good noise-immune circuitry, here's one of the better documents I've come across.

As an afterthought while doing the PCB design I also added an opto-isolated serial interface to the circuit, which in theory could be used for cell voltage reporting etc, but I haven't actually tested it or implemented anything in software.

PCB Design

Once the schematic design was complete, it was time to lay out the PCB. Doing PCBs can be quite an artform - easy enough to start with, difficult to do well, impossible to perfect. I actually find it quite theraputic.

The final PCB design is shown to the right. Click here for a version with labelled overlays summarising each section. The blue background represents a ground plane. This is one of the most important aspects of PCBs designed to operate in (EMI) noisy environments such as electric vehicles. With a 2-layer board like this one, anyone familiar with PCB design will know how much more difficult it can be to lay out the rest of the circuit with only a single layer for all other tracks! I could have gone for a 4-layer board of course, but they're more expensive. It's mostly through-hole components because I find them easier to work with for hand-assembled boards than surface mount. The downside is much bigger component footprints, and hence bigger and more expensive boards. An upside of larger footprints and pin spacings is that it's easier to route boards with fewer layers.

The final PCB design (click for enlargement)

The transistors are shown on the top but actually get mounted below the PCB, so that their metal tabs can be fastened to a heatsink (with insulator between, since their potentials vary).

Another "gotcha" with construction is that the actual resistor values in the voltage samplers is quite critical. They are rated to 1% tolerance/error, but over 32V range this becomes quite significant (~30mV). As such, when building the boards I manually matched sets of 8 resistors to within 0.1%.

In the past I've etched PCBs myself, but these days I don't think it's worth my time. PCB manufacturing companies can do it quite economically and with much better results, so I prefer to outsource. The two companies I have experience with are Gold Phoenix PCB and PCBCart. I've never received a single faulty board from either company. Gold Phoenix (qualitatively) seem to do slightly neater boards and may be better if targeting mass production, but PCBCart have an easier online quote/ordering system for small orders. I got 20 of these BMS boards done for about AU$9 each, including FedEx shipping and the one-off tooling fee.

Microcontroller Software

The software that runs on the ATmega16 microcontroller was written in C, using the AVR Studio development environment. Despite ending up a few hundred lines long, the functionality of the code is pretty simple. This summarises the main loop (iterating at about 10hz):

• Sample each cell, flagging any above or below voltage thresholds
• Enable/disable shunts for any cells above the shunting threshold (3.6V)
• Set status LEDs - on for in-voltage, off for error voltage, or flashing when shunt enabled.
• Read temperature sensor inputs
• Set output relays if any cell was below, above or shunting respectively, or over-temperature

The complete code listing may be downloaded below. For those who haven't worked with AVRs before, the AVR Studio software is free from Atmel (with registration). You'll also want to install the WinAVR GCC compiler so you can code in C instead of assembly! To transfer code to the microcontroller, I usually just use an inexpensive USB AVRISP type programmer. (I also have a JTAGICE programmer which does some nifty things like in-system debugging, but it's overkill for simple projects.)

Build Your Own

For anyone interested to build their own BMS, you are welcome to download the Eagle PCB files and the AVR project/code from this project. To reiterate, these files are provided freely but without any warranty, support, guarantees etc. YMMV!

Schematic and PCB files from Eagle

AVR Studio project and code

Total parts cost worked out somewhere around $50 per board in low volumes ($6/cell), so it's definitely competitive vs commercial BMSs.. depending on how much you value your own time! They take perhaps an hour or so per board to construct.

I would stress that with a mission critical application like a BMS, you must be very confident that the system is working as it should before you deploy it in any real-world applications. Damaged batteries are not worth the risk! (That's why we run BMSs in the first place, right?)

~Ian Hooper, March 2012

Comments

	Scott Speight on 9th May 2012 ian, they ought to knight you just for the presentation of this material, not to mention the excellent content. Wishing you miles of smiles and looking forward to another visit with Steve when you can fit us in.
		Ian Hooper on 9th May 2012 Thanks for the kind words, Scott!

	dev on 4th Jun 2012 Hi thanks for posting this article i would like to know how can we validate this result ?
		Ian Hooper on 7th Jun 2012 Hi dev, you're welcome to download the resources if you want to build your own, links just before this comment section. I mostly wrote this article just to give others some information and ideas for BMS design, I haven't really tested the system enough myself to be 100% confident with it long-term yet! (I'm still building the electric car it'll be going in.) So as they say: Your Mileage May Vary!

Please note that due to spam problems all comments are moderated
and comments advertising other websites are automatically rejected!