Login| Sign Up| Help| Contact|

Patent Searching and Data


Title:
SMART BATTERY SYSTEM WITH MODULARITY
Document Type and Number:
WIPO Patent Application WO/2019/010126
Kind Code:
A1
Abstract:
A smart battery system is disclosed. The smart battery system is a collection of interconnected battery modules each having a plurality of module cells that included a plurality of batteries with reconfigurable interconnections. The smart battery system uses microcontrollers to compute an optimal configuration for an operational cycle using load requirements and a discharge model for each battery. The discharge model is based on the characteristics of each battery in the smart battery system and can be used to determine the degradation of batteries for fault detection. If a fault is detected, battery modules may be configured to share energy in order to effectively eliminate the fault. Despite a close electrical relationship, the battery modules may be spaced apart and/or replaced easily as necessary.

Inventors:
POTTEIGER, Timothy (2005 21st Ave S, Apt. 303Nashville, Tennessee, 37212, US)
PENCE, Kenneth R. (900 Tower Place, Nashville, Tennessee, 37204, US)
KARSAI, Gabor (225 Harpeth Wood Drive, Nashville, Tennessee, 37221, US)
Application Number:
US2018/040593
Publication Date:
January 10, 2019
Filing Date:
July 02, 2018
Export Citation:
Click for automatic bibliography generation   Help
Assignee:
VANDERBILT UNIVERSITY (305 Kirkland Hall, 2201 West End Avenu, Nashville Tennessee, 37240, US)
International Classes:
H02J7/04; G01R31/40; H01M10/44
Attorney, Agent or Firm:
CORNETT, David A. et al. (Meunier Carlin & Curfman LLC, 999 Peachtree Street NESuite 130, Atlanta Georgia, 30309, US)
Download PDF:
Claims:
CLAIMS

1. A smart battery system, comprising:

a plurality of interconnected battery modules that each comprise a module controller and one or more module cells, wherein each module cell comprises a plurality of batteries and switching circuitry, wherein the switching circuitry in each module cell is controllable by the module controller so that the plurality of batteries in the one or more module cells may be connected in a plurality of possible switch configurations;

a system controller that is communicatively coupled to the module controllers for each battery module, wherein the system controller is configured by software instructions to:

receive a load requirement from an application,

determine a degradation models for each of the plurality of batteries, derive an optimal switch configuration based on the load requirement and the degradation models, and

cause the module controllers of each module to adjust the switching circuitry to match at least part of the optimal switch configuration.

2. The smart battery system of claim 1, wherein each battery module has multiple input ports such that a charge source can be connected to each module simultaneously with a discharge circuit connected to each module.

3. The smart battery system of claim 1 or claim 2, wherein the module controller for each battery module determines and stores all possible switch configurations for each respective battery module and the derived optimal switch configuration is determined from these stored possible switch configurations.

4. The smart battery system of claim 3, wherein the possible switch configurations are stored in a hash table in a memory of the module controller. 5. The smart battery system of any of claims 1-4, wherein the module controller for each battery module determines and stores a module resource allocation matrix for each respective battery module, wherein the module resource allocation matrix specifies what blocks of each module cell physically contains nonfaulty batteries.

6. The smart battery system of claim 5, wherein a constraint solver executing on the module controller is used to determine a state of the blocks of each battery cell that comprises a battery module, wherein the state of a block indicates a valid switching configuration of a primary partition and a secondary partition of that block.

7. The smart battery system of claim 6, wherein the constraint solver is given constraints to follow to ensure safety, to manage the batteries when there is a fault among the primary partition batteries, and to maintain a constant voltage level.

8. The smart battery system of claim 6 or claim 7, wherein the constraint solver comprises a Z3 solver.

9. The smart battery system of claim 8, wherein the 73 solver produces and stores valid configurations for possible future states.

10. A method for configuring a smart battery system, the method comprising:

providing a smart battery system, wherein the smart battery system comprises a

plurality of interconnected battery modules that each comprise a module controller and one or more module cells, wherein each module cell comprises a plurality of batteries and switching circuitry, wherein the switching circuitry in each module cell is controllable by the module controller so that the plurality of batteries in the one or more module cells may be connected in a plurality of possible switch configurations, and a system controller that is communicatively coupled to the module controllers for each battery module; obtaining a load requirement from an application connected to and powered by the smart battery system;

identifying a switch configuration for the smart battery system;

obtaining battery parameters from each battery in the switch configuration;

detennining a discharge model each battery in the switch configuration;

computing, based on the discharge models, a prognostic metric for the smart battery system in the switch configuration;

comparing the computed prognostic metric to other prognostic metrics for other switch configurations of the smart battery system; and

repeating the obtaining, determining, computing, and comparing to find an optimal switch configuration for the smart battery system, wherein the optimal switch configuration enables the smart battery system to operate longer, accommodate a fault better, or operate for more cycles than other switch configurations of the smart battery system; and

applying the optimal switch configuration to the smart battery system.

11. The method of claim 10, wherein each battery module has multiple input ports such that a charge source can be connected to each module simultaneously with a discharge circuit connected to each module.

12. The method of claim 10 or claim 11 , wherein the module controller for each battery module determines and stores all possible switch configurations for each respective battery module and the derived optimal switch configuration is determined from these stored possible switch configurations.

13. The method of claim 12, wherein the possible switch configurations are stored in a hash table in a memory of the module controller. 14. The method of any of claims 10-13, wherein the module controller for each battery module determines and stores a module resource allocation matrix for each respective battery module, wherein the module resource allocation matrix specifies what blocks of each module cell physically contains nonfaulty batteries.

15. The method of claim 14, wherein a constraint solver executing on the module controller is used to determine a state of the blocks of each battery cell that comprises a battery module, wherein the state of a block indicates a valid switching configuration of a primary partition and a secondary partition of that block.

16. The method of claim IS, wherein the constraint solver is given constraints to follow to ensure safety, to manage the batteries when there is a fault among the primary partition batteries, and to maintain a constant voltage level.

17. The method of claim IS or claim 16, wherein the constraint solver comprises a Z3 solver.

18. The method of claim 17, wherein the Z3 solver produces and stores valid

configurations for possible future states.

Description:
SMART BATTERY SYSTEM WITH MODULARITY

CROSS-REFERENCE TO RELATED APPLICATION

[0001] This application claims priority to and benefit of U.S. provisional patent application no. 62/528,776 filed July 5, 2017 and U.S. provisional patent application no. 62/544,263 filed August 11, 2017, both of which are fully incorporated by reference and made a part hereof.

BACKGROUND

[0002] Batteries are now relied on to supply power for applications, such as aircraft or vehicles, which have little or no tolerance for failure. Accordingly, smart battery systems, which have multiple batteries that are each monitored and controlled to prevent a power disruption during an operation cycle (i.e., period of use), have been proposed. Because these systems typically include a large number of batteries within a housing, they are heavy and bulky and are generally not usable for applications (e.g., aircraft or vehicle) which must carefully allocate space and/or weight distribution. A need, therefore, exist for a smart battery system that is fault tolerant, optimized for operation/cycles, and modular.

SUMMARY

[0003] Accordingly, in one aspect, the present disclosure embraces a smart battery system (i.e., system) with modularity. The smart battery system includes a system controller in communication with a plurality of interconnected battery modules (i.e., modules). Each battery module includes one or more module cells (i.e., cells or blocks), wherein each module cell consists of one or more batteries (e.g., a primary battery and a spare battery). Each battery module further includes a module controller that is connected to the system controller and to switching circuitry and protection circuitry in the module.

[0004] The smart battery system may automatically optimize its performance. The module controller in each battery module is configured by software to optimize the battery module's lifetime (i.e., the number of operation cycles) and/or operational life (i.e., maximum duration of an operation cycle) by configuring the switching circuitry to connect the module cells in a particular switch configuration (i.e., setup). In other words, the setup may be adjusted to maximize the time that the battery module can provide sufficient power to properly enable the application (e.g., aircraft or vehicle) or to extend the number of cycles that a module cell may be charged/discharged. The setup may be continually evaluated (e.g., every 2 seconds) and compared with other possible setups to accommodate changes (e.g., due to changing operating requirements and/or ambient conditions).

[0005] The system may also automatically adapt to faults. Module controllers of multiple battery modules may communicate (e.g., via the system controller). This inter-module communication can be used to configure (or reconfigure) the switching circuitry of two or more battery modules to exchange energy when necessary. For example, a faulty battery in a first battery module may be switched out so that it no longer supplies power to the application (e.g., aircraft or vehicle) and replaced by an operative battery in a second module.

[0006] A method (e.g., software algorithm) for performance optimization and/or fault adaptation utilizes a discharge model evaluated for each battery. The discharge model includes parameters related to a battery's degradation to determine an expected performance of the battery in a given setup for a particular operating scenario (i.e., load requirement).

[0007] Battery parameters used in a discharge model may include (but are not limited to) internal resistance, charge (i.e., Coulomb) counts, diffusion constant, and capacity. For example, the internal resistance of a battery may increase after each operation cycle. Accordingly, the value of the internal resistance and/or the instantaneous rate of change of the internal resistance between cycles may be used to model the discharge rate of a battery. The algorithm may then evaluate valid switch configurations between and/or within battery modules to determine a prognostic metric for each valid switch configuration.

[0008] A prognostic metric corresponds the predicted operation time for a given setup for a particular load requirement. The load requirement may be determined by the application. For example, a flight controller for an aircraft operating for a period (i.e., flight time) may compute a load requirement for the smart battery system as a minimum voltage/current threshold that the smart battery system must operate at or above for at least the period.

[0009] To determine a prognostic metric for a particular switch configuration, the system controller uses the discharge model for each module cell the particular setup to determine the maximum operation time that the smart battery system can meet the load requirement. A plurality of switch configurations are evaluated in this manner to determine prognostic metrics for each. The prognostics metrics are then compared to determine the optimal switch configuration (e.g., configuration with largest prognostic metric).

[0010] Typically, a single switch configuration does not optimally optimize lifetime (i.e., number of operation cycles) and operation time; therefore, a choice between must be made. In an exemplary embodiment of the optimization method, a switch configuration that maximizes lifetime (i.e., number of cycles) is determined at the beginning of an operation cycle. During the operation cycle, new switch configurations that maximize operation time are determined every few seconds.

[0011] One advantage of the present disclosure is that discharge models may be computed on a regular basis (e.g., every 2 seconds) and the optimal switch configuration can be continually reevaluated to accommodate battery degradation, faults, or changing load requirements. Because the smart battery system is modular, changing battery modules is easily accommodated by the algorithm.

[0012] Faults in a module cell can be detected at a battery module level using circuitry to monitor battery health (e.g., storage capacity, charge status, faulty cells, etc.). If a fault in a module cell is detected the module controller change a switching configuration within a module cell. For example, a module cell may include a primary battery and a secondary battery. If the primary battery becomes faulty, the module controller may adjust the switching with the battery module so that the spare battery replaces or supports the energy delivery of the primary battery.

[0013] The same principle may be applied at a system level because the module controllers can communication with each other via a centralized system controller. For example, if a battery module becomes faulty, the system controller may trigger the module controllers to adjust their energy delivery to replace or support the faulty battery module.

[0014] The system controller also communicates with the application (e.g., aircraft or vehicle) and may provide a message to the aircraft regarding the status of the smart battery system for example, a low battery alert or battery status may be sent to the application. In this way, the application may respond to the smart battery (e.g., change its load requirements).

[0015] The foregoing illustrative summary, as well as other exemplary objectives and/or advantages of the disclosure, and the manner in which the same are accomplished, are further explained within the following detailed description and its accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

[0016] Figure (Fig.) 1 schematically depicts a smart battery system with modularity according to an exemplary embodiment of the present disclosure.

[0017] Fig. 2A is a simplified illustration of an exemplary module cell with two blocks. [0018] Fig. 2B is an illustration of states that the primary partition for a block can achieve.

[0019] Fig. 2C is an illustration of states that the spare partition for a block can achieve.

[0020] Fig. 3 is an illustration of an exemplary resource allocation matrix.

[0021] Fig. 4 is an algorithm that illustrates how a decision is made for reconfiguring a module.

[0022] Fig. 5 is a flow chart of an algorithm for optimizing the operational life of a battery module according to an exemplary embodiment.

[0023] Fig. 6A and Fig. 6B are illustrations of the power system setup for a simulation comprising two series branches powering two tandem motors.

[0024] Fig. 7 are simulation results showing the measured voltage of a single lithium-ion polymer cell compared to the model.

[0025] Fig. 8 are simulation results showing the load condition put on the 6S1P battery.

[0026] Fig. 9 are simulation results showing only the module remaining useful life for module 1 as all of the batteries within the module have the same parameters and at any given time have the same remaining useful life.

[0027] Fig. 10 are simulation results showing the module remaining useful life for module 2, battery 1.

[0028] Fig. 1 are simulation results showing the module remaining useful life for module 2, battery 2.

[0029] Fig. 12 are simulation results showing the module remaining useful life for module 2, battery 3.

[0030] Fig. 13 are simulation results showing the module remaining useful life for module 2, battery 4.

[0031] Fig. 14 are simulation result showing, in the Z3 configuration generation test, the transition from a configuration matrix to another configuration matrix given a change in the resource matrix.

[0032] Fig. IS illustrates an exemplary device that can be used as a portion of or all of one or all of the application controller, module controller and the system controller. DETAILED DESCRIPTION

[0033] The present disclosure embraces a modular, smart battery system having a plurality of battery modules. Each of the battery modules is configured with a module controller that can self-evaluate the condition/operability of the batteries in the battery module and can communicate this condition/operability to a system controller. Based on the reported condition/operability, the system controller can compute an optimal switch configuration to allow the batteries in the plurality of battery modules to be connected in a configuration that is optimized. The optimized configuration may allow battery modules to share energy to compensate for a faulty battery, distribute the load requirement evenly amongst batteries, extend cycle (i.e., operation) time, and or extend the number of usable cycles.

[0034] An exemplary smart battery system is shown in Fig. 1. In particular, Fig. 1 schematically illustrates the logical connections between the components in a smart battery system 102 connected to an application 104. Not shown in Fig. 1 are the power connections.

[0035] As shown in Fig. 1, an application 104 powered by the smart battery system 102 is communicatively coupled to a smart battery system 102. Exemplary applications 104 include an aircraft, vehicle, or a subsystem therein. The application 104 typically includes an application controller 106, such as a flight controller that interfaces with a system controller 108 of the smart battery system 102. For example, the application controller 106 may communicate load requirements (e.g., flight time, current voltage, etc.) to the smart battery system 102. In another example, the smart battery system 102 may communicate a status to the application controller 106, such as a remaining battery life.

[0036] The smart battery system 102 includes a plurality of battery modules 110. Each battery module 110 includes a module controller 112. The module controller 112 includes processing (e.g., micro-controller, processor, FPGA, ASIC) that can be configured by software instructions to monitor battery status and to control a network of switches that interconnect the batteries 114 into a circuit for delivering power to the application 104.

[0037] The switches 116 in the battery modules 110 function to connect the batteries 114 in series or parallel connections to form a configuration. The configuration may include multiple series or parallel connections of batteries within a module cell 118 or between module cells 118.

[0038] The module cells 118 in each battery module 110 include at least two batteries (e.g., a primary and a spare) 114. The batteries 114 are typically lithium-ion (Li-ion) polymer batteries, but other battery types (e.g., NiMH, NiCd, etc.) are within the scope of the present disclosure.

[0039] The smart battery system 102 may include two or more battery modules 110. Each battery module 110 may include any number of module cells 118 and each module cell 118 may include two or more batteries 114.

[0040] An advantage of the smart battery system 102 is its modularity. Because the battery modules 110 are typically identical, they may be removed, replaced and/or added on to as necessary without altering the operation of the overall system In addition, battery modules 110 may be made small to comport with the size requirements of an application and may be positioned in the application to distribute weight. For example, a convention battery system having battery modules combined in a unitary package may not be suitable for an aircraft or vehicle because of space constraints and/or loading (i.e., weight). The smart battery system 102; however, allows for module cells 118 to be spaced apart, thereby distributing the load. In addition, each module cell 118 of the smart battery system 102 may be made smaller to conform with the available space on an aircraft or vehicle.

[0041] Fig. 2A is a simplified illustration of an exemplary module cell 118 with two blocks 202, 204. In this embodiment, each block 202, 204 contains two batteries 114 that are laterally connected. One battery 114 is in the primary partition 206 of each block 202, 204. The other battery 114 is in the spare partition 208 of each block 202, 204. The states that the primary partition 206 for a block can achieve are shown in Fig. 2B and the states that the spare partition 208 can achieve are shown in Fig. 2C. The state of the each of the two blocks 202, 204 is defined as the conjunction of the state of the primary partition 206 and the state of the spare partition 208. One property that this module design exhibits is that given N module blocks, the module 110 has the capability of reconfiguring N batteries in any location within the module 110 out of operation and still be able to maintain the required voltage of an N series branch. This property allows toleration of N faulty batteries at any location within the module 110. Additionally, this property allows the module 100 to balance module cells 118 if there are more than N non-faulty batteries by excluding batteries 114 that limit the module's operation time from the configuration to preserve the remaining useful life of the limiting batteries.

[0042] To help facilitate safety, diodes (e.g., Schottky diodes) 210 are included in the design and are included in the current path for the discharge states. The diodes 210 are included as hardware interlocks during discharge. During operation, if a battery 114 in a block 202, 204 drops off in voltage significantly, it will cease to discharge if the lateral battery 114 in the block 202, 204 does not experience that same drop off in voltage. If a series branch is significantly lower than other branches in operation due to a battery 114 dropping off in voltage and there is not a lateral battery in operation for the battery that dropped off in voltage, that series branch will cease to discharge.

[0043] Some battery module 110 embodiments advantageously have multiple input ports. This allows a charge source (not shown) to be connected to the module 110 at the same time a discharge circuit (not shown) is attached to the module 110. This eliminates a need for external switches to connect the module 110 to a charge source or discharge circuit based upon the phase of the module 110. Simply, the module 110 is told what phase it is in, be it discharge, charge, rest, or optimize and the module 110 configures itself to connect to the charge port, discharge port, or neither.

[0044] Reconfigurable systems have an application for reliability to instill resilience against faults and allow for continued operation. In this case, a reconfigurable battery module scheme is defined and the software that determines the configuration states that can be achieved for continued operation is outlined. The ability of the battery module 110 to be reconfigured in the presence of a fault allows the module 110 to have a higher mean time to failure than a static configuration. This functionality is achieved by having a closed loop interaction between a module controller 112 and the battery module 1 0. The interaction takes place by the module controller 112 proactive to an operation cycle. Essentially, given the resources of the battery module 110, a software program computes all of the possible discharge configurations for the battery module 110 that can be achieved during operation in the case that resources are lost due to faults. The configurations are stored in a hash table in the module controller memory, that can be accessed during operation to determine the next configuration the battery module 110 needs achieve when a fault occurs. This control flow is done to limit the latency of state restoration with respect to fault tolerance.

[0045] A portion of the controller software involves producing a valid configuration given a set of resources as inputs. The set of resources is read in from a file and stored in a two- dimensional array where there are two columns and N rows. This two-dimensional array is referred to as the module resource allocation matrix 302 and it specifies what blocks 202,204 physically contain nonfaulty batteries 114. The rows of the matrix represent blocks 202, 204. The left column in a row represents whether the spare partition 208 is occupied by a non-faulty battery 114 and the right column represents whether the primary partition 206 is occupied by a non-faulty battery 114. An example resource allocation matrix 302 is shown in Fig. 3 that represents a module 110 that contains non-faulty batteries placed in the primary partitions 206 of the cells 118 and faulty batteries placed in the spare partitions 208 of the blocks 202, 204. The top row is denoted row 1, which is connected as the power source and the bottom row is denoted as row 3, and is connected to ground.

[0046] Given a resource allocation matrix 302, a method to determine the state of the blocks 202, 204 is needed. Constraint programming is chosen as the method to determine the state of the blocks 202, 204. Constraint programming is a method to solve problems by formulating them as mathematical equations and inequalities that contain variables whose values are sought. The solution to the constraint problem satisfies the inequalities. Constraint solvers are tools that can efficiently calculate the solution. For example, the Z3 constraint solver is a very efficient solver that can solve a large variety of constraint problems (Z3 is a theorem prover from Microsoft Research with support for bitvectors, booleans, arrays, floating point numbers, strings, and other data types). One such problem involves solving for the allocation of resources in fractionated spacecraft. In this case, the 23 solver is used to determine a valid configuration of the battery module 110. The solver is given constraints to follow to ensure safety, to manage the batteries 114 when there is a fault among the primary partition batteries, and to maintain a constant voltage level. The resulting state of the blocks 202, 204 is represented as a 2-dimensional array where there are also two columns and N rows as there are in a resource allocation matrix. The first column is the enumerated value of the state of a spare partition 208 in a block. The second column is the enumerated value of the state of a primary partition 206 in a block. The definitions of the constraints that the Z3 solver has to satisfy are outlined below. The output set of numbers for most of the definitions correspond to enumerations given to states in Figs. 2B and 2C. For instance, if the output set for a spare partition 208 configuration contains the value 1, 1 would be in reference to the first state in the spare partition state table in Fig. 2C. It should be noted that these constraints do not allow all configurations that are physically valid given the module design. Instead, these definitions are provided to allow the solver to be able to satisfy the requirement of having N batteries in series given any resource allocation matrix that has at least N non-faulty batteries.

[0047] Definition 1: If a partition is not occupied or contains a faulty battery, there are certain states that the partition is not allowed to achieve. The crux of this definition is that if a partition is not occupied, then the state of that partition cannot involve the battery being connected as there is no battery in the partition or the battery in the partition is faulty.

[0048] Definition 2: In a module with N blocks, the module has to have N batteries in series.

[0049] Definition 3: If a spare is put in series with a primary battery in a block, the spare partition must not be connected to any other spare partition and the spare partition must be connected to the primary partition in the same block.

[0050] Definition 4: If a primary partition is in parallel with a previous primary, the previous primary must be in parallel and the spare partition should be connected to the previous block.

[0051] Definition 5: If a spare replaces a primary battery in a block, the spare partition must not be connected to any other spare partition.

[0052] Definition 6: If a primary battery is in parallel, the spare partition must not be connected to the spare partition of the previous block.

[0053] The controller software uses the 73 solver to produce and store valid configurations for possible future states. The possible future states are determined by sequencing through the set of all possible resource allocation matrices and basing whether or not those matrices have less or the same amount of resources as the current resource allocation matrix. The assumption made is that from this moment in time forward, no batteries will be added and only faults will occur leading to future possible states containing less resources. The controller then computes a valid configuration for all of the future possible resource states if the constraints are satisfiable. If a valid configuration is found, it is stored in a hash table. The hash table is a 2- dimensional array where the column is used to store the valid configuration and the column is accessed by a hash. The first column element is a valid configuration indicator that is a 1 if a valid configuration stored in the column and a 0 if there is not. The even elements in the column correspond to the spare configuration elements and the odd elements correspond to the primary configuration elements. The column setup is outlined in the Equation 11. The hash function is shown in Equation 12.

[0054] Switching to accomplish cell balancing can be used to provide better performance for multiple configurations such as microgrids, series branch modules, lateral series branch modules, and parallel modules. With respect to performance, criteria can vary. Criteria for voltage has been used for cell balancing. Criteria for state of charge (SOC) has also been used. With respect to prognostic based objectives, cell balancing has been applied to maximize the objective of increasing lifetime of the battery. Described herein are optimization methods similar to cell balancing according to the prognostic measure of remaining useful life to improve the objective of operation time from an unbalanced static battery configuration.

[0055] To compute remaining useful life (RUL), an electrochemistry based model is used. Given a state of charge, a load is given to the model and the model is iterated until the voltage falls below the voltage threshold which is representative of a deprivation of available charge and accordingly used to indicate the end of discharge. Cell balancing is needed within the modules to elongate the operation time of the module. The algorithm is shown in Fig. 4 and dictates how a decision is made for reconfiguring a module. The valid configuration that produces the highest remaining useful life is chosen.

[0056] An exemplary method for configuring a smart battery system is shown in Fig. 5. The method begins 502 by obtaining a load requirement from the application. For example, a load requirement may include a voltage, current, power, energy requirement and may include an expected duration (e.g., flight time). [0057] The method then computes prognostic metrics for a plurality of switch configurations. For example, a valid switch configuration is identified 504. Battery parameters for the batteries in the identified switch configuration are obtained 506 to determine a discharge model 508 that simulates operation of the smart battery system in the identified switch configuration. Exemplary battery parameters may include internal resistance, charge (i.e., Coulomb) counts, diffusion constant, and capacity.

[0058] Using the determined discharge module 510, a prognostic metric may be computed 512. A prognostic metric may be the amount of time that the smart battery can meet the load requirement (i.e., operation lifetime). The amount of time may then be compared 514 to a threshold set at the operation time described by the load requirements. In this way, switch configurations having prognostic metrics that do not exceed the threshold may be eliminated.

[0059] After all valid switch configurations are evaluated, the optimal switch configuration is selected 516. For example, the optimal switch configuration may be the switch configuration that provides the longest amount of time that the smart batter can meet the load requirement.

[0060] The process of examining and selected switch configuration to maximize operation life can be repeated on a regular basis. For example, the process may be automatically repeated after a period of one or more seconds. Alternatively, the process may be repeated as necessary due to a change in the smart battery system (e.g., a faulty battery detected) or a change in the application (e.g., a change in load requirements). In this way, the battery can respond to changes in the smart battery's ability to meet the load requirements or may respond to changes in the application's power requirements.

Examples/Simulations

[0061] The below experimentation involves characterizing a lithium-ion polymer battery using a magnetic levitation vehicle as a high current draw, simulating the power system for a subscale electric aircraft, and obtaining a new valid configuration for the module in the presence of a faulty battery. The experimental hardware setup comprised a magnetic levitation vehicle, a power system, and a monitoring system that is used to characterize a lithium-ion polymer battery. The power system is comprised of a 6S1P lithium-ion polymer battery. Toe current draw from the battery was varied to observe the voltage response. Then, the Nelder- Mead method to obtain fitting battery model parameters.

[0062] An exemplary aircraft power system simulation involves using power values that would be seen from a small-scale aircraft as a load to the power system for an aircraft that takes on the aerodynamic parameters of an Edge 5 0T aircraft. The Edge S40t is a subscale electric unmanned aircraft vehicle constructed by the safety-critical avionics branch at NASA Langley Research Center that is 98 inches in length, 100 inches in wing span, 1881 inches 2 in wing area, and weighs 47.4 pounds. The power system setup comprises two series branches powering two tandem motors, as shown in Figs. 6A and 6B. Each series branch contains two SS2P lithium- ion polymer battery packs. The SS2P denotation indicates that the battery pack either has five sets of cells in series where each set has two cells in parallel or there are two parallel strings where each string has five cells in series. The implementation is up to the battery manufacturer. To take advantage of the data gathered from the lithium-ion polymer battery, the disclosed simulation of the power system takes on an equivalent setup where instead each series branch is a two-cell module that contains four SS1P lithium-ion polymer battery packs.

[0063] For the simulation, the parameters for a set of batteries are derived from the data gathered. Four batteries take on the parameters gathered from the maglev high current draw data. Those four batteries are placed in module 1. The parameters for the four batteries to be placed in module 2 are obtained by drawing parameters from a distribution that is centered at the parameters of the data gathered. The batteries in module 2 are varied so this simulation can demonstrate the effect of the module cell balancing algorithm on a single module. The first simulation entails keeping the batteries static. The second simulation entails allowing the optimization strategy to be used during runtime.

[0064] Z3 configuration generation flow is tested. First, the configurations that can be achieved are generated and stored in a hash table. Then, a hazardous state occurs within a battery that may be the temperature of the battery exceeding a threshold. We assume the battery fault is detected and prompts a need to reconfigure. Given the new set of non-faulty batteries, we construct a new resource allocation matrix. The resource allocation matrix is used generate a hash and is used to access a valid configuration.

[0065] The maglev high current draw model was fit using the squared difference between the model and the measurement as an objective for the Nelder-Mead search algorithm. The measured voltage of a single lithium-ion polymer cell compared to the model is shown in Fig. 7. The load condition put on the 6S1P battery is shown in Fig. 8. The parameters found for the model are shown in Table I, below:

lithium-Ion Polymer Battery Parameters

[0066] The aircraft power simulation for both tests involves a load of 1500 W being drawn from the power system This load corresponds to maintaining an airspeed of approximately 24.6 m/s. The graphs for the remaining useful life values from both tests are shown in Fig. 9, Fig. 10, Fig. 11, Fig. 12, and Fig. 13. Fig. 9 shows only the module remaining useful life for module 1 as all of the batteries within the module have the same parameters and at any given time have the same remaining useful life. What can be taken away from these graphs is that during the simulation where the batteries remain static, battery 2 for module 2 is the limiting battery. That is, it exhibits the shortest battery operation time of 850 seconds. This causes module 2 to have an operation time of 850 seconds as the module operation time is defined as the operation time of the limiting battery. When the modules are allowed to reconfigure, the module 2 batteries are seen to become more balanced and eventually exhibit remaining useful life values that are very close in time. Being defined by the limiting battery, the module 2 operation time is defined by the operation time of battery 1 which is 990 seconds. This is an increase of 16.5% in operation time for module 2. The trade-off for optimizing module 2 is an increase in load on module 1 during the periods for which the optimization operation occurs. This causes the operation time of module 1 to decrease to 940. Hence, module 1 becomes limiting to the overall operation time. Overall, the remaining useful life increases from 850 to 940 which is a 10.6% increase. [0067] In the Z3 configuration generation test, the transition from a configuration matrix to another configuration matrix given a change in the resource matrix is shown in Fig. 14. A fault occurs in the primary battery of module cell 2. This leads to the second column of the second row of the resource allocation matrix to be changed to 0. This new resource allocation matrix is used as a hash to access the configuration hash table. The configuration accessed is shown as the destination in the transition from the original configuration in Fig. 14. The change is that the primary battery in module cell 2 is disconnected and instead the spare battery in that module cell is connected.

Computing Environment

[0068] As noted above, the disclosed smart battery system may include an application controller, a module controller and/or a system controller.

[0069] FIG. IS illustrates an exemplary device that can be used as a portion of or all of one or all of the application controller, module controller and the system controller. As used herein, "controller" may include a plurality of controllers. The controllers may include one or more hardware components such as, for example, a processor 1521 , a random access memory (RAM) module 1522, a read-only memory (ROM) module 1523, a storage 1524, a database 1525, one or more input/output (I/O) devices 1526, and an interface 1527. Alternatively and/or additionally, controller 1520 may include one or more software components such as, for example, a computer-readable medium including computer executable instructions for performing a method associated with the exemplary embodiments. It is contemplated that one or more of the hardware components listed above may be implemented using software. For example, storage 1524 may include a software partition associated with one or more other hardware components. It is understood that the components listed above are exemplary only and not intended to be limiting.

[0070] Processor 1521 may include one or more processors, each configured to execute instructions and process data to perform one or more functions associated with a controller for controlling a battery system Processor 1521 may be communicatively coupled to RAM 1522, ROM 1523, storage 1524, database 1525, I/O devices 1526, and interface 1527. Processor 1521 may be configured to execute sequences of computer program instructions to perform various processes. The computer program instructions may be loaded into RAM 1522 for execution by processor 1521. As used herein, processor refers to a physical hardware device that executes encoded instructions for performing functions on inputs and creating outputs. [0071] RAM 1522 and ROM 1523 may each include one or more devices for storing information associated with operation of processor 1521. For example, ROM 1523 may include a memory device configured to access and store information associated with controller 1520, including information for identifying, initializing, and monitoring the operation of one or more components and subsystems. RAM 1522 may include a memory device for storing data associated with one or more operations of processor 1521. For example, ROM 1523 may load instructions into RAM 1522 for execution by processor 1521.

[0072] Storage 1524 may include any type of mass storage device configured to store information that processor 1521 may need to perform processes consistent with the disclosed embodiments. For example, storage 1524 may include one or more magnetic and/or optical disk devices, such as hard drives, CD-ROMs, DVD-ROMs, or any other type of mass media device.

[0073] Database 1525 may include one or more software and/or hardware components that cooperate to store, organize, sort, filter, and/or arrange data used by controller 1520 and/or processor 1521. For example, database 1525 may store hardware and/or software configuration data associated with input-output hardware devices and controllers, as described herein. It is contemplated that database 1525 may store additional and/or different information than that listed above.

[0074] I/O devices 1526 may include one or more components configured to communicate information with a user associated with controller 1520. For example, I/O devices may include a console with an integrated keyboard and mouse to allow a user to maintain a database of images, update associations, and access digital content. I O devices 1526 may also include a display including a graphical user interface (GUI) for outputting information on a monitor. I/O devices 1526 may also include peripheral devices such as, for example, a printer for printing information associated with controller 1520, a user-accessible disk drive (e.g., a USB port, a floppy, CD-ROM, or DVD-ROM drive, etc.) to allow a user to input data stored on a portable media device, a microphone, a speaker system, or any other suitable type of interface device.

[0075] Interface 1527 may include one or more components configured to transmit and receive data via a communication network, such as the Internet, a local area network, a workstation peer-to-peer network, a direct link network, a wireless network, or any other suitable communication platform. For example, interface 1527 may include one or more modulators, demodulators, multiplexers, demultiplexers, network communication devices, wireless devices, antennas, modems, and any other type of device configured to enable data communication via a communication network.

Conclusion

[0076] The disclosed embodiments of a battery module can provide use in battery subsystems where maintainability, adaptability, and fault tolerance are necessary. The optimization strategy is shown to increase the operation time of a module and to balance the batteries with respect to remaining useful life under a known future load that is constant. This means that the optimization strategy can be used in flight modes such cruise and loiter. This could be of particular use in reconnaissance missions using hybrid-electric aircraft such as the Condor. Such missions involve the electric subsystem primarily being used only in loiter mode during the surveillance portion of the mission to facilitate quiet operation of the aircraft. The reconfiguration scheme is shown to provide domain-specific semantics and to be able obtain a valid configuration in the case that a battery becomes faulty during operation.

[0077] In some embodiments, the method described includes additional operations. For example, at the end of an operation cycle battery parameters may be obtained from the batteries in the smart battery system to determine a discharge model for batteries at the end of a cycle that can be used to determine the switch configuration to provide the maximum number of operation cycles. This switch configuration may be used as the initial switch configuration at the start of the next operation cycle.

[0078] In the specification and/or figures, typical embodiments have been disclosed. The present disclosure is not limited to such exemplary embodiments. The use of the term "and/or" includes any and all combinations of one or more of the associated listed items. The figures are schematic representations and so are not necessarily drawn to scale. Unless otherwise noted, specific terms have been used in a generic and descriptive sense and not for purposes of limitation.