Multi-physics co-simulation of battery thermal model

The analysis and proper design of the energy storage system is a critical concern in the product development phase of Hybrid Electric Vehicles (HEVs). Development of high fidelity models and comprehensive analysis of the battery pack are critical and can significantly improve performance and reduce cost. Incorporating high fidelity battery model into a vehicle model can significantly increase the model fidelity and improve the fidelity of the vehicle model. This project features a novel modeling approach developed in order to analyze the battery pack in high performance hybrid-electric vehicles using a multi-physics co-simulation approach. This modeling capability can be extended to other multi-physics systems in order to develop high fidelity models while significantly decreasing the computational costs. The modeling approach used in order to analyze the battery performance, includes three domains: electrical, structural and fluid. The high fidelity electrical domain model includes, an individual cell model (multiple cells can be arranged to form a battery module and/or pack), control unit, and power cycle in the form of a table. The structural heat transfer model is developed using Finite Element Modeling (FEM) software Abaqus 2016 and includes all the battery pack components. The fluid domain model is developed using Abaqus 2016 and includes the model of cooling fluid which removes heat from the cooling plate. The new modeling and simulation capability presented, provides a novel approach which builds upon the co-simulation capability of the SIMULIA package. The cell model was calibrated using experimental test results. Finally the project lists the next steps of the project and potential applications of the battery pack model. In order to develop a high fidelity model of the battery cell, Modelica language is used. Modelica is an open source, object oriented, and equation based modeling language which can be used to easily model complex physical systems containing, electrical, mechanical, hydraulic, thermal, electronic, control and process oriented subcomponents. A wide array of open source Modelica Libraries have been developed, providing rapid and scalable model development capability. Dymola is a commercial modeling and simulation environment based on Modelica modeling language. Dymola has a built in capability to simulate object oriented models as well as export models as Functional Mock-up Units (FMU). FMUs are executable function files, generated following the Functional Mock-up Interface (FMI), which is a tool independent standard to support model exchange and co-simulation of dynamic models. In order to streamline the development of a cell model, the open source Electric Energy Storage (EES) library developed jointly at Austrian Institute of Technology and Vienna University of Technology was used. The library contains sub-components of different complexity such as individual cells and stacks interacting with loads, battery management components and charging devices.The EES library components are designed as universal components allowing the end users to easily simulate specific scenarios by varying the parameterization. The use of Modelica language allows seamless modifications of the equations used in each subcomponent. For the purposes of this analysis, the built in LinearDynamicImpedance cell model was modified in order to properly define the cell model based on experimental data. The Batteries package includes models for individual cells as well as stacks of ns  cells connected in series and np  cells in parallel. A single cell component is selected for the purpose of this analysis. The single cell model features a positive (pin_p), a negative (pin_n) and an optional temperature connector (heatPort) which is activated as cell parameters are defined as a function of temperature. Model can consider the effects of aging by considering both calendaric aging and cycling. Calendaric aging is estimated from time which for the purposes of the current analysis is minimal and therefore removed from the model. Cycling is directly proportional to absolute transferred charge Qabs . Aging of the cell mainly influences the performance by decreasing capacity and increasing the internal impedance. The cell capacity is temperature dependent and decreases with increased transferred charge due to cycling. The single cell model features a single, temperature dependent, ohmic impedance which does not consider the increase in impedance due to aging. The EES library contains a battery management block (Cycling) which is used to implement a rule based control of the battery cell. It has three boolean outputs which control the operation of the charging unit, power cycle look up table and the cell. The battery management block can be used to cycle the cell a predefined voltage range, while limiting the maximum current draw during discharge and charging current. The EES also includes a constant current, constant voltage (CCCV) charging device which charges the cell with constant current until the constant voltage level is reached. The battery module under study contains twelve individual cells arranged in two series sets of six parallel cells. Subcomponent labeled load includes the charging unit, power cycle look up table, a switch and the cycling rule based control unit. Switch works by disconnecting the power cycle when the cell/module drops below Vmin  and connecting the charger. Similarly as the voltage reaches the constant voltage level, the switch disconnects the charger and connects the power cycle to continue the power cycle.  In order to study the effects of heating on battery performance and investigate the cooling power needed to ensure the safe operation of the battery pack the heat generated during cycling is calculated and the temperature of the cell is calculated by the heatCapacitor model. An additional thermal resistance is included in the model to represent the heat resistance of the skin of the cell. In order to create a high fidelity model of the battery module, a transient heat transfer model is developed. Each part of the module was meshed on part using standard linear tetrahedron elements (DC3D4) with a global size 4 and applying curvature control by allowing the maximum deviation factor to equal 0.6. Under the assembly module a dependent instance was created containing all components and a surface of type geometry, named INTERFACE, was created using the internal surfaces of the cooling plate. The surface was used to define a heat flux interaction with the fluid domain model. In order to define the Co-simulation interaction property between electrical, structural, and fluid domain models, an input file, named Standard.inp, was generated using the structural heat transfer model created. Abaqus CAE interface does not allow the definition of the co-simulation interaction, thus the input file was edited. In order to create a high fidelity model of the cooling fluid, a transient CFD model is developed. The thermal properties of the coolant which is a mixture of 50% water and 50% Ethylene glycol. The fluid model, which was generated to fill the void in the cooling plate part, was meshed on part using CFD linear tetrahedron elements (FC3D4) with a global size 4 and applying curvature control by allowing the maximum deviation factor to equal 0.6. Under the assembly module a dependent instance was created and three surfaces of type mesh, named INLET, OUTLET, and INTERFACE were created.The INTERFACE surface was used to define a heat flux interaction with the structural domain model. The INLET surface was used to define the fluid inlet boundary conditions. Similarly, the outlet boundary conditions were applied to the OUTLET surface. Similar to the structural heat transfer model, in order to define the Co-simulation interaction property between electrical, structural, and fluid domain models, an input file, named Fluid.inp, was generated using the CFD model created. Abaqus CAE interface does not allow the definition of the co-simulation interaction, thus the input file was edited. Co-simulation between Abaqus/Standard (standard heat transfer model) and Abaqus/CFD (fluid domain model) is governed by an additional process, the SIMULIA Co-Simulation Engine (CSE) director. Typically the CSE director is automatically invoked and the co-simulation parameters are stored in the co-simulation configuration file. In order to execute co-simulation between models generated using Abaqus products and co-simulation format FMU files, the Abaqus command line should be used to invoke the CSE director and the co-simulation configuration file should be manually generated. Proper execution of co-simulation requires:

1. Proper definition of the interaction between the three models as outlined in the CSE User’s Guide and API reference Guide.
2. Compatible and consistent definition of co-simulation time and step size.
3. Definition of co-simulation parameters in the co-simulation configuration file as specified by the CSE director.
4. Definition of the co-simulation master and slave.

In preparing the Dymola model of the battery module for co-simulation, an FMU of type co-simulation and version 1.0 was generated. More information about generating an FMU using Dymola is available in the Dymola User’s Guide. The FMU file generated using Dymola is a compressed file which contains a Dynamic-link library (DLL) executable file as well as a model description file in XML (eXtensible Mark-up Language) format. The CSE director automatically assigns FMU model instances as slave models. Definition of the interaction between the three co-simulation models required manually editing the structural model input file, Standard.inp. Similar to the structural heat transfer model, definition of the interaction between the three co-simulation models required manually editing the structural model input file, Fluid.inp. For the purpose of this analysis, communication between three models was defined using surface regions. A complete description of fields available for exchange between co-simulation models interface regions refer to section 17.2.1 of the Abaqus User’s Guide.  The co-simulation controls, using the keyword scheme modifier, was used to assign the fluid model as a slave. The keyword incrementation, was used to force the slave to take appropriate step sizes and report the results at time tnext. The co-simulation configuration file defines the simulation properties of the system and the numerical methods employed to simulate the system in its defined environment. This includes:

• components: subsystem simulator programs used in the co-simulation,
• component instances: subsystem simulations performed using identified simulators,
• connectors: available input and output simulation results from each subsystem,
• connection sets: pairing of subsystem simulation results,
• connection categories: time in the co-simulation when these pairings are relevant or active, and
• model of computation: numerical method used in the co-simulation.

In order for the configuration file to correctly identify the co-simulation parameters and be accepted by the CSE director, the following requirements must be satisfied:

1. XML well-formedness. The CSE director or any other XML authoring tool can confirm the well-formedness.
2. Abiding by the CSE schema definition. The rules and constraints are described formally in the CSE API kit.
3. Internal consistency of references.
4. Topological and algorithmic consistency. The definition of co-simulation and model parameters within the configuration file should be consistent with the problem definition in each subcomponent.
5. External consistency of references. The author of the configuration file should ensure consistency of names registered with the CSE director and each subcomponent.

The first four requirements can be verified by using the datacheck option. External consistency of references can only be verified at run time. The configuration file contains six sections as described in the following paragraphs. For more details about the co-simulation configuration file refer to the CSE User’s Guide and the CSE configuration schema documentation.

1. Document header

The first two lines in the file identify the document as an XML compliant and define the XML root element as <CoupledMultiphysicsSimulation>, which uniquely defines the document as relevant to the CSE. The next line segment will add the header. Various information can be included within the header however the only required information is the schema version.       2. Components The components section of the configuration file defines each model included in the co-simulation. A brief description of the master model, including the unit definitions and co-simulation variables will identify the master subcomponent to the CSE director. The CSE director identifies all Abaqus products using the bottomUpImplementation keyword. All other subcomponents are identified using the topDownImplementation keyword. For further details about the different implementation techniques refer to API User’s kit.       3. Component Instances The section identifies the subsystem models participating in the co-simulation and associates these models with the simulation executables defined in the components section. This section also provides additional basic assertions about the simulation behavior of the subsystems. For the purpose of the co-simulation performed for this study, the two Abaqus simulation products each correspond to a single model (there is a one to one relation between the simulation executable and the simulation model). In a more general use one to many relationships can be defined; for example, an Abaqus/CFD to Abaqus/Standard pairing of two separate models. Using the initial conditions option and setting the sendBeforeReceive option to false, the CFD model will not communicate its initial conditions until it receives the initial conditions from the master model (Standard). The default mode for the sendBeforeReceive option is true and therefore it is not included the Standard component instant definition.       4. Connectors Connectors define the variables that enter and leave a component instance. The connector element provides the association between the component instance name and the variable name and declares whether the variable is input or output. The name attribute for the connector element is used for internal reference in the configuration file. For Abaqus simulation models and FMUs, there is no need to match the variables listed in input files with corresponding variables in the configuration file.       5. Connection Sets Connections establish the associations between connectors. Pairing between all input and output variables is checked by the CSE director. In cases where connector elements have multiple variables defined, the connection elements must pair two connector elements that exactly complement each other in the sense that one connector’s input variable count match the other’s output variable count, and vice versa. In the case of co-simulation performed for this analysis, three independent connection sets are defined. The first two connection sets of type field, establish communication between the fluid and standard model. First set defines the communication from CFD to Standard model and the second set defines communication from Standard to the CFD model. Type field connection ports will communicate both the variable magnitude as well as field units. The third connection set establishes communication of signals between the Standard model and the FMU.        6. Execution The execution element describes all the details of the numerical method used to perform the co-simulation. Execution element is generalized to enable a hierarchical arrangement of an arbitrary number of component instances. The term atomicActor refers to each individual simulation participant in co-simulation; whereas, a composite actor refers to a grouping of simulation participants. In the case of the co-simulation performed for this analysis, the CSE uses the Gauss-Seidel algorithm and the CSE will negotiate the variable exchange time between participants between the three simulations by selecting the maximum of the time increments preferred by the three codes. For more information about the algorithm types and exchange time negotiation options refer to the CSE configuration schema.    Finally, in order to perform the co-simulation, all input files (Abaqus input files and the FMU) as well as the co-simulation configuration file are stored in the current directory of the Abaqus Command. The following command prompts will initiate the co-simulation on machine earth and communication with the CSE director is established through port 65533. For a complete list of available ports for co-simulation refer to the Abaqus User’s Guide.       call abaqus cse -j Confige_File -config Confige_File.xml -listener 65533 call abaqus fmu -fmu Electrical_System.fmu -instance Electrical _System -csedirector earth:65533 call abaqus -j Standard -csedirector earth:65533 call abaqus -j Fluid -csedirector earth:65533 After the first command prompt is used, the CSE director awaits for the other co-simulation components which can be invoked in an arbitrary order. During co-simulation, the CSE director generates individual log file for each co-simulation file which can be used for debugging. A separate .msg file is also generated which provides a brief description of the co-simulation steps and possible errors encountered during co-simulation. In order to calibrate the cell model, a single battery cell was tested under high current discharge conditions and experimental results were provided. For the purposes of the discharge test, the ambient temperature was at 23±2oC. The cell was initially charge with the voltage equal to the maximum cell voltage and a current of 2.5A for 2.5 hours. Afterwards the samples were paused for 1 hour. The test cell was placed under a thermal camera and device under testing (DUT) was discharged with a current of 40 A until the voltage dropped below the minimum cell voltage or the thermal camera detected a temperature of over 80 C. For the purpose of the calibration the distribution of temperature was constant over the surface. During discharge the cell is discharged with a current of 40A and after 200 seconds the cell reaches 80oC at which point the discharged is stopped. the cell model can be adjusted by including num serially connected RC elements. In order to calibrate the model only the first RC elements were adjusted in order to achieve good agreement between experimental and model results. Performance of the battery pack under high loading conditions is of great concern in the development of high performance HEVs. The current draw from the battery pack can be limited; however extended high current draw can result in development of local high temperature regions which can significantly reduce the battery performance and battery life. The purpose of this study is to estimate the effects of high current draw on battery life and ensure the cooling system can efficiently remove heat and eliminate high temperature regions. For the purpose of this study the model will undergo two types of loading conditions. In order to study the long term effects on battery life, the model will be executed with loading cycles that represent the long term use of the battery pack. In order to study the temperature profile in the battery pack, the loading cycle will feature long periods with maximum current draw. In order to complete this analysis, which will be completed in the next step of work, a model of the battery pack which can include hundreds of battery modules is developed. This model will also include control logic that will monitor the temperature of the battery pack at predetermined locations and limit the current draw to prevent thermal or electrical damage to the battery pack. The development of the battery pack model will also require further testing of an individual battery cell to better define the fast and slow transient behavior of the cell. The transient behavior is represented by several RC elements included in the cell model. The final stage of this project will include the integration of the battery pack model into the vehicle model. The battery pack model developed in this chapter is an example of high fidelity multi-physics model which can take the place of a low fidelity model based on experimental results. The development of high fidelity models within a single modeling environment, such as Matlab or Simulink, is often unfeasible or at best can lead to a significant increase in the computational costs as many functional components of the vehicle feature multi-physics systems. It should also be noted that the development of finite element model of system components in junction with equation based models and rule based control is often impossible within a single modeling environment. Therefore the use of co-simulation in the development of subcomponent models and integration with the vehicle model can lead to a significant increase in model fidelity and reduced computational cost.