Effecient BMS

[splin]

splin: I'm not sure why you are so dubious of microcontroller reliability. The PIC I am using has an onboard watchdog timer that operates to monitor the operation of the hardware and firmware, I have used hundreds of thousands of PIC chips in the last 20 years with very few failures. Modern microcontrollers are very robust and with only simple firmware running on them rebooting is not required.

You've used hundreds of thousands of PIC chips in the last 20 years? That's an extraordinary claim. I presume you mean that you've designed PICs into things which have sold in large numbers. But unless they have been continuously monitored when operating such that you have decent statistics on failure rates and types of failure (e.g. hard faults, lock-ups, 'glitches' and other soft faults) along with operating hours then it's irrelevant. We know that billions of things with microcontrollers have been made and used but reliable statistics on their reliability are not easy to find. Anecdotal evidence is not very useful when you are designing a safety critical device. Many soft faults (internal corruption of state) will go unnoticed if the affected functionality is not used, particularly if the device is power cycled regularly which is the case for a large subset of embedded systems.

You are right that a lot of embedded systems are very reliable but failures do happen. For example I am aware of a large company that is currently suffering microcontroller corruption problems, probably temperature related, in one of their safety related products. Sorry but I can't provide any more detail. I have seen plenty of devices that stop working and require power cycling including mobile phones, TV set top boxes and PVRs - but these are fairly to very complex systems and the failures are most likely software related but the end result is the same.

Millions of devices now use microcontrollers in motor control applications where failure will cause a FET or IGBT to latch on and blow a fuse or trip a breaker and this is now a rare event. Almost all modern motor drive systems are microcontroller / software controlled and reliability is very high.

Yes, perhaps I have overstated the problem. But as I said before important systems will generally be well designed by companies with a great deal of experience in the field and with plenty of resources to thoroughly test at all stages of design and production.

There seem to have been a lot of incidents of white goods, particularly washing machines and tumble dryers catching fire lately. Probably the vast majority will have been due to faulty or under-rated components, poor electrical connections in high power circuits etc. but I wonder if any have been caused by microcontroller faults? It wouldn't surprise me as these are aggressively cost reduced.

Microcontrollers can and do go wrong so it is essential to provide appropriate safety protection measures. It is my belief that microcontrollers and their firmware are rather less reliable than dedicated hardware. Especially so when the hardware is relatively simple. The more complex the microcontroller used in an embedded firmware solution and the more complex the firmware, the worse it gets.

I will update the circuit today to show the fuses and mosfet gate resistors, it is likely that the systems will be built as two parts with the monitoring circuit on 1 board and the boost / invert circuits on a sperate board with the PWM signals on a connector between the boards, there will be fuses between the pack and the charge passing circuits.

Please tell me you are going to include independent over-voltage monitoring and cut-outs?

No system is perfect and digital systems most definately have more failure points than a simple analog ones, however I think that the advantages of modern digital control systems far outweigh their drawbacks and added complexity.

True, but the vast majority of systems are not safety critical (other than if they catch fire!) and soft failures are merely inconvenient. If a system is safety critical then all the possible failure modes need to be considered. In most cases simple measures, like fuses in your case, may be the solution but not always - not a good solution in a braking system for example.

I am currently in the prototype programming phase of this system and initial communications protocol testing, the plan is to do this whole device in stages with the first being the monitoring system, once the monitoring system is up and running the additional stages for charge transfer will be added. Other topologies for charge transfer will also be consdered and tested depending on the results of the system performance.

Thanks again, Brenden

I have to agree with an earlier poster - surely it would be much more efficient to transfer the excess energy to the whole pack or alternatively to the top and bottom of the battery pack rather than just the adjacent cell? That way the diode losses at least will be much lower. It does mean that some energy will get 'bounced' between cells with higher voltages but it should be much more efficient than transferring via multiple hops.

To transfer to the whole pack you need only one inductor between the N and P channel FETs and have one diode transferring energy to the top of the pack and have an additional FET connecting the top of the inductor to the bottom of the pack. That's 5 extra FETs, but 5 less inductors and because the efficiency would be much better you could get away with smaller FETs/inductors.

[ZeroStatic]

all: I have updated the schematic.

splin: Yes I have personally monitored many thousands of PIC microcontrollers I have designed into traffic control equipment, we manufactured and maintained this equipment long term. This equipment is solar powered and much if it is trailer mounted hire equipment and subject to abuse. Many of these devices use over 200 PIC chips per device in a networked configuration and the PIC controllers are extremely reliable despite operating in adverse conditions.  Typically I have programmed these devices in assembly code and very seldom are there watchdog resets or chip failures. Vandalism is far more common. Most of the equipment I designed uses Lead-Acid AGM battery technology.

I do not consider this system to be life critical and need the kind of over the top, belt and braces approach you are advocating to prevent over charging, with independent over-voltage monitoring and cut-outs.

In the event of a software failure or communications timeout the cell controllers will shut down the PWM to prevent over charge or over discharge conditions. I will also probably build in an alert system should any cell voltage be measured far out of specification where the cell controller will send a long break condition to reset the cell controller array.

Testing and calibration of the cell volatge monitoring system is now under way and testing of the prototype is going well thus far.

Thanks again for all the comments and feedback, Brenden.