Robert Spotnitz argues the case for industry-standard modelling software for proper design of battery systems.
Designing battery-powered devices today is much more difficult than it should be. The typical electrical engineer (EE) has no idea of how to select a battery, and so must rely on a battery expert. This situation has led to a process in which a device is designed first, and then a battery is found to power it.
This process all too frequently fails; for example, the first iPod batteries needed to be replaced, and there were complaints about the first PlayStation portables not having enough runtime. More seriously, safety incidents have occurred that required product recalls.
Disasters usually occur because of inadequate testing or incomplete understanding of the battery’s behaviour. Testing is expensive and time-consuming, and development plans may not include enough time or budget for enough of it. These problems could largely be avoided if there were a way for EEs to include the battery upfront in their designs.
If EEs had access to models they could evaluate battery performance as part of the design process for a device. Any problems with battery performance could be identified early in the design process and corrective action taken. The low cost of modelling compared to physical testing would allow a much more extensive test regimen to be executed, so that the battery design could be thoroughly vetted. This approach seems obvious, but it has yet to be adopted because of the difficulty in obtaining battery models. Battery developers do not provide simulation models for their products.
Because battery developers don’t provide models, some especially enterprising EEs have constructed their own models[1,2,3]. Unfortun-ately, these models don’t represent battery performance very accurately, and the parameters required for the models are not readily available for most batteries. This lack of simulation models requires that a more elaborate battery design process be followed.
Typically EEs consult in-house battery experts or a pack provider for battery information. These experts don’t rely on models to develop recommendations; they rely on their experience. Battery experts who support design of battery-powered products are mainly responsible for qualifying batteries and so are well versed in battery testing, but are not usually comfortable with battery modelling. They will develop a design based on their understanding of the requirements and then test the physical battery to see how well it meets the requirements. Testing must necessarily be limited because it is expensive and time-consuming, and only if the initial design falls well short of requirements will a second design iteration be attempted. This process inevitably leads to the quality and safety problems mentioned earlier.
Battery experts almost universally agree that the current design process is flawed, but believe there is no other alternative because batteries are just too complex. Only an expert with years of experience is capable of muddling through the intricacies of battery design, and only testing can determine whether a battery works. This view leads the industry to accept gross inefficiencies.
Consider that a battery developer carries out testing worth hundreds of thousands of dollars and then sells to several customers (OEMs) who must each spend hundreds of thousands of dollars in testing to verify performance. This expensive and time-consuming redundancy could be largely eliminated if OEMs could simply verify models provided by battery developers. Even greater than the millions of dollars wasted annually in redundant testing is the opportunity cost for improving batteries and expanding the battery market.
Developers lose a valuable opportunity to improve their batteries by failing to provide models. If customers used models to predict battery performance and then found discrepancies between predicted and actual functioning, this would identify gaps in the developer’s understanding of the battery. The wise developer would use the customer’s feedback, find out why the model didn’t agree with data, and so improve his knowledge of the product. Such a process of comparing model with data would lead to an greater understanding of batteries and thus to better-designed batteries. The ability to model battery behaviour would enable new users to design products appropriately and to use batteries efficiently.
Correctly designing a new battery-powered device is an expensive and time-consuming process because of the need for extensive testing. The availability of models would allow new devices to be rapidly designed and so would result in new applications for batteries. The market for batteries could be greatly expanded by reducing the development cost of battery-powered devices and making batteries easier to use.
The electronics industry has long made use of third-party software as a means of reducing costs and creating standards. When several companies adopt a common software platform they share the development and maintenance costs, and obtain a better product because it enjoys more thorough testing and feedback simply by virtue of having more users. Third-party software tends to be more powerful in terms of scope and features than in-house software because third-party software is accessible to a wider audience. For example, academics and industrial researchers can use third-party software in their work and provide feedback on it. If a standard software package emerges for a particular industry there are additional benefits.
An industry-standard software package enhances communication among members of that industry. Software enables an unparalleled level of detail to be communicated at lightning speed, and the dissemination of common models in an industry allows its members to more quickly exchange ideas and product information. For example, if a company develops a better op-amp, it can post a SPICE model that will enable circuit designers to quickly assess its benefits. Similarly, new circuit designs can be posted that all designers can evaluate. The battery industry can follow the same paradigm; however some way to initiate the process is needed.
Introducing computer-aided design to the battery industry creates a ‘chicken and egg’ problem. The benefits of battery modelling can only be realised by using such models, but developers will only be willing to produce these once the benefits of modelling are accepted. It is an expensive and risky undertaking for developers because they have little, if any, competence in battery modelling. Third-party software offers a way out of this dilemma. Battery developers can use third-party software to simulate their products and provide models to OEMs. The availability of third-party software resolves the dilemma and a first product, Battery Design Studio, is now readily available.
Battery Design Studio (BDS) is the first third-party battery design software. It is primarily a platform for the exchange of battery information, but already has many tools for data analysis, battery design and simulation. BDS provides a common platform for battery users, pack developers and cell makers.
Battery users can view BDS as a virtual laboratory in which an entire array of cell characterisation techniques (such as cycling and abuse testing) can be carried out. For example, BDS mimics a battery cycler (see Figure 1). Users can programme their custom test procedures and execute them on battery models, in just the same way as physical batteries are tested.
Note that the BDS cycler interface has one entry not normally found in physical cyclers: the heat-transfer coefficient. This value determines how effectively heat is transferred between the battery and its environment; its value can significantly affect battery performance, especially cold temperature performance. If the heat-transfer coefficient is a low value, which might happen if the cell is not exposed to air flow in a baffled refrigerator, then the cell may heat up during discharge and perform better than a cell placed in a refrigerator with good circulation. Modelling forces users to understand the test conditions and so helps avoid potential disasters when batteries go into products.
Pack developers can use BDS to design and test packs[4]. Packs can be tested using the same cycler interface described above. Packs can be designed using a drag and drop process (see Figure 2) to create an electrical schematic. Once the schematic is created and a package is specified, the physical layout can be defined, again using a drag and drop process (see Figure 3). Abuse testing is of particular interest for packs and can be carried out using BDS[5]. For example, the initial temperature of one cell can be set to a high value so that it will go into thermal runaway, and then the behaviour of the other cells monitored to see their response. For the notebook pack shown in Figure 3, the whole pack has the best chance of going into thermal runaway if cell #5 goes first and so pack abuse tolerance would be enhanced by improving heat-transfer to that cell.
Both users and pack developers need cell models in order to do their work. BDS allows cell developers to create cell models and then distribute those models in an encrypted form so as to protect all proprietary information.
Carmakers, through the U.S. Advanced Battery Consortium, have set certain targets for batteries and developed procedures for evaluating how well batteries meet these targets. For example, one type of hybrid electric vehicle requires that the battery be capable of providing 25kW pulses for 10 seconds over a state of charge range corresponding to 50 Wh. The procedure to validate this behaviour is somewhat complex but has been programmed into BDS so that battery developers can quickly estimate how well their products meet the carmakers’ requirements. BDS created a standardised means of data analysis that has undergone thorough testing; carmakers can thus feel confident that results obtained with BDS conform to their requirements.
OEMs should require their battery suppliers to provide simulation models, and then verify that the simulation models are accurate by comparing simulation results with experimental data. If discrepancies between simulations and experimental data are found they should be reported to the battery supplier so that the models can be improved. This iterative process (sometimes called science) will allow the complexity of battery systems to be conquered and enable real engineering of battery systems.
Why does the battery industry need third-party design software? Such software offers a proven path for battery developers to reduce costs, shorten development cycles, add value to their products and expand their markets while improving the performance, quality, reliability and safety of battery-powered devices.
[1] S. C. Hageman, EDN (1993).
[2] S. C. Hageman, EDN (1995).
[3] S. Gold, in 12th Annual Battery Conference on Applications and Advances, Long Beach, CA, 1997, p. 215.
[4] R. Spotnitz, J. Weaver, G. Yeduvaka, J. Fan, D. Magnuson, G. Au, R. Thompson and C. Hurley, in 42nd Power Sources Conference, Philadelphia, PA, 2006, p. 563.
[5] R. M. Spotnitz, J. Weaver, G. Yeduvaka, D. H. Doughty and E. P. Roth, Journal of Power Sources 163:1080 (2007).
Robert Spotnitz, President, Battery Design LLC
rspotnitz@batdesign.com
www.batdesign.com
