Handling Complexity in Virtual Battery Development with a Simplified Systems Modeling Approach

Abstract

Lithium-ion battery systems are a core component for electric mobility, which has become increasingly important in the last decade. The rising number of new manufacturers and model variants also increases competitive pressure. Competition is shortening development times. At the same time, the range of technology options for batteries is growing steadily. Fast and well-founded concept development is becoming even more essential in this increasingly complex environment. For this purpose, various model-based systems engineering (MBSE) methods are analyzed and evaluated. Based on this, the battery modeling framework is derived and described, tailored to the needs of battery development. The validation of the methodological approach is demonstrated by the simulation workflow from an electrical cell characterization to the thermal evaluation of different cooling methods.

1. Introduction

The increasing importance of battery systems for electric mobility leads to the need for higher efficiency in the early product development stages. In product development, diverse challenges exist, which increase complexity and development effort. Different engineering fields, which this paper defines as domains, are linked in the product development process. Domains are, for example, the traditional mechanical and thermal development foci and the electrical dimensioning of battery components. The use of different domains is necessary to analyze the physical interactions within the battery and to optimize the product design based on the interdependencies. For example, in the design of vehicle cooling systems, initial thermal simulations at the cell, module, and system levels can provide an initial estimation of the necessary cooling concept. This makes it possible to optimize the battery product based on various input parameters and use cases to meet specific development goals. These can include performance enhancement or cost reduction. Additionally, newer focus areas such as life cycle assessment (LCA) gain importance to these core domains. All these domains must be combined to fulfill the overall requirements for the given product development. Besides technological changes, there has also been a change in development conditions. In general product development, lifecycles are shortened, whereas the number of new products and variants increases [1]. In addition, numerous innovations are emerging across all product levels of battery systems. These innovations can be both technical and economic [2]. With digital tools and simulation methods, the market introduction of battery technologies can be accelerated [3]. Therefore, in early development phases, virtual models are needed to bundle and assess these different perspectives in a joint evaluation. Due to the increasing complexity and functional integration of modern products, the coordination effort in development is continuously rising. In addition, the increasing requirements can partly be secured with simulations. These also imply an effort in the interface consideration of these different simulation models. An example of previous research in the field of simulation models is the research project Model2Life. This project optimized the transition from first-life vehicle batteries to second-life batteries in stationary storage systems with different simulation models [4]. In the following, additional ideas of systems engineering are presented to simplify the approach and connect it to the battery development process. This builds the baseline for further research in this publication. MBSE provides a general method for structured modeling and design of development tasks. The different sub-methods of MBSE were evaluated and assessed for the requirements of battery development. It could be shown that the existing methods provide extensive support during the development. Still, due to their complexity, they do not allow the necessary development speed, especially in the early development phase, to evaluate and compare different concepts. Consequently, the approach proposed here focuses on reducing complexity. It aims to demonstrate that essential development decisions can be made in the early phases of product development, even with a reduced variety of models.

2. Complexity in Battery Engineering

An example of a complex development task is the design of high-voltage traction batteries for electric vehicles. From the authors’ perspective and expertise, the battery is increasingly becoming a unique selling point. The timeline of battery development is highly relevant for the success of companies. The goal of shortening the time to market is achievable only through innovative changes in the development process. The main challenges are the vast solution space with numerous interactions between components and the complexity of the product and production process. This challenge has already been addressed at the cell level and needs to be extended to the system level [5].

Various technical domains come together in battery development. The choice of cell chemistry significantly influences the theoretical maximum performance of the whole battery system. Via the electrical layout, essential system parameters such as system voltage and energy content are tailored based on the chosen battery cells. The choice of a specific battery cell significantly influences the battery system [6]. The mechanics must ensure integration into the vehicle and corresponding crash safety. Thermal management is necessary for optimum battery temperature control to maintain service life and performance. The system is controlled and regulated by the battery management system [7]. To enable consistent modeling, a tool, a language, and a methodology have to be combined [8] (p. 136).

2.1. General Development Models

The purpose of development models includes abstracting a complex process and visualizing how activities are carried out to increase transparency. This allows the process to be simulated and analyzed, leading to subsequent optimization [9] (p. 236).

In industry, a commonly used approach for product development is the stage-gate process and V-model. In the stage-gate approach, the product development process is divided into various phases (“stages”), from the product idea to market readiness, each of which passes through control points (“gates”) [10] (p. 726). The purely sequential processes can be supplemented by introducing overlapping and parallel process steps within the framework of simultaneous or concurrent engineering. Building on this fundamental idea, the V-model extends purely sequential models into an interdisciplinary development model [11] (p. 40). The defined structure with less room for iterations represents the main challenge. Figure 1 visualizes a conventional process from A- to C-sample. The development process is summed up by three V-models in serial order, both with a development phase and a validation phase. In industrial practice, errors are unavoidable, so new changes in the sample phases are also necessary during the validation phase. In the event of an unexpected error during the validation of the A phase, the B phase must be extended, and the end of the phase is therefore shifted to B*. Two different process deviations can be identified: a deviating process with time delay and a deviating process with resource delay.

2.2. Systems Engineering Approaches

In industry and research, different models are developed and combined to design domain-specific tasks. The domain is the area or field of application that the system is being designed for. At the same time, the models are simplified representations of the system used to predict its behavior and evaluate design options later. Due to the combination of several domain-specific models, an efficient and robust information exchange is needed. For the solution of such multi-domain development tasks, there are several potential options for solutions in practice. Those methods are part of the so-called systems engineering method. Systems engineering is quite an established method of joining independent systems toward a common goal [12].

One challenge in systems engineering is the complexity of information handling. Each domain, model, or organizational entity uses individual documents, resulting in a lack of consistency in information availability. In consequence, there is a wish for an approach with one single source of truth for information and data. Model-based systems engineering (MBSE) is an overall approach to deal with this challenge [13]. It enhances the interface handling of systems engineering, digital engineering, and model-based engineering approaches in terms of a holistic view of the complete system embedded into a digital model. MBSE includes activities such as requirements analysis, design, verification, and validation through all development and life cycle phases [14] (p. 25). The modeling perspective allows us to link multiple sub-models from different disciplines and observe their dependencies. Each sub-model answers specific questions within a larger model or framework. Key aspects are, for example, the handling of complexity, which is not reduced but managed by the approach, and the possibility of more agile instead of linear procedures [14] (p. 25), [15]. In practice, MBSE is expected to improve mainly system quality, design, performance, and productivity [16]. In the following, different methods within MBSE are described and assessed regarding their suitability for battery system development. Finally, an approach for fast and efficient modeling of battery system concepts is shown and validated by the example of a single-cell simulation workflow.

2.3. Challenges in Battery Modeling

Modeling battery systems represents a multi-domain problem to solve. In the EV market, a wide variety of product specifications exist for each product structure element. Many requirements of battery electric vehicle (BEV) manufacturers need to be fulfilled within the product specifications. On the other hand, however, there is a comparatively small number of variable input parameters in the development process. That leads to a high count of elements in the solution space, which have to be evaluated for the requirements-based product concept. Compared to complex mechanical problems, where there are many different input parameters, battery modeling approaches can be characterized by simple parameters in a first evaluation. These challenges lead to the need for lower-complexity models that can map the needed information with minimum computing effort.

Interviews with industry partners were conducted to validate the proposed challenges. On this basis, the perspectives of seven institutions and companies in the field of battery development were obtained. The interviewees are all closely involved in battery development but in different positions and scopes of development work. The interviewees range from cell manufacturers to service providers and OEMs. Part of the results are shown in Figure 2. One observation focused on the rise of changes in requirements or product design. The majority of change requests were identified in later sample stages. This is somehow critical since the later a product change must be implemented during the development process, the more cost and time challenges arise due to a more complex change propagation [17] (p. 333). It can be concluded that the late product changes are a challenge in battery design. To address this challenge, the use of digital modeling techniques was proposed in the interviews. While there has been a general appreciation of simulation and modeling, especially the concept phase relies mainly on personal experiences and estimations. Detailed modeling happens in later stages of development but mostly only with limited complexity. Multiphysics modeling, which integrates several views and interdependencies, is used only in pilot projects within the industry.

In conclusion, it is shown that there is an opportunity to reduce development efforts by using more detailed and connected modeling approaches. The implementation and evaluation of the possible successes have to be proven in research and industry. A basis is given in this publication.

3. MBSE Methodologies

A literature review is conducted to investigate the relevance of model-based development in research and evaluate existing approaches. This review will identify the most commonly used methodologies for model-based systems engineering (MBSE). First, the research results are presented as an overview of the approaches and afterward assessed. For the assessment, the focus is the specific development needs of automotive batteries. In conclusion, the challenges in product development are summarized, which represent the requirements for an adapted modeling approach and a more simplified tool for early development phases.

3.1. MBSE Methods in Literature

The following nine MBSE methods were identified based on the literature review and afterward qualitatively assessed by the authors. The key assessment criteria are intuition, reusability, adaptability, flexibility, scalability, comparability, the possibility of multi-domains, and integrated validation. The chosen methods are among the most commonly used approaches in systems engineering. The assessment was on a qualitative basis with the evaluation of each method with the individual criterion. The evaluation is a rating from no fit to full fit in five levels of confidence.

The ARCADIA (ARChitecture Analysis and Design Integrated Approach) method can be applied to hardware and software projects. The aim is to strictly separate needs and solutions. Therefore, a practitioner will have to go through three interdependent phases: need analysis and modeling, building and validating the architecture, and requirements engineering. Hence, on the first level, what the user of a system must achieve is examined. On a second level, what the system has to fulfill for the user is then determined. How the system will comply with the demands and how it will be developed is specified on the consecutive levels. Unlike other approaches, ARCADIA provides not only the method but also a language: DSML (Domain-Specific Modeling Language). DSML entails different types of diagrams for different engineering levels. The diagrams describe viewpoints with individual foci to offer various stakeholders and domains perspectives [18,19].

The MagicGrid or MBSE Grid method can be displayed in a matrix notation. The rows represent three different levels of abstraction, which can be compared to the viewpoints in ARCADIA. Columns, on the other hand, represent four important facets of systems engineering: requirements, behavior, structure, and parameters. Each layer of abstraction has to be worked through. The deeper the layer, the more abstract the problem. Starting with the first level of abstraction, the black-box perspective, the operational analysis of the whole system is carried out, whereas the white-box perspective pictures the behavior of various subsystems [8] (p. 139). The last layer describes the system’s solution in terms of the aforementioned facets. A tool to apply the MagicGrid method is, e.g., the Cameo Systems Modeler, which uses generic languages like SysML (System Modeling Language) or UML (Unified Modeling Language) [20]. Though SysML is an approved language on its own, it should be mentioned that it was originally developed out of UML [14,21].

STRATA uses different levels of abstraction, such as MagicGrid. The domains regarded at each level are source requirements, behavior, architecture, verification, and validation. While applying the method, a practitioner iterates through the different levels until the attention to detail satisfies the demand. STRATA is compatible with the tools Core and Genesys [19] (p. 2), [20] and implemented using SDL (System Definition Language) [22].

OOSEM’s (Object Oriented Systems Engineering Method’s) key objective is to provide a flexible framework that allows subsequent changes within the design and development process. The approach enables classical top-down procedures with given activities. It can be implemented using SysML or UML. Contrary to some other methods, an assigned tool does not exist [22]. The method separates the logical and the functional structure of a problem, which are connected via so-called “allocation” relationships [14,21,23].

FAS (Functional Architecture for Systems) focuses on the separation of functional and logical elements of a system like OOSEM. Functionalities are worked out of use cases and thereafter grouped depending on common activities. The goal of the separate consideration of logical and functional elements is the possibility to evolve several technical solutions for the same functional architecture and also be able to reuse the functional architecture for different product families and generations [21,24,25].

Harmony SE consists of three main activities: requirements analysis, system functional analysis, and architectural design. The approach follows a classical “V” structure [26], including the previously mentioned activities on the left side and test and integration tasks on the right side [22]. The method can be implemented using UML and the IBM Rational Rhapsody tool [20,23] (p. 164054).

The OPM (Object-Process Methodology) approach enables a simultaneous visual and textual representation of a system. The visual representation is realized through diagrams and OPD (Object-Process Diagram), while the textual representation is realized through OPL (Object-Process Language), which is a subset of the English language. The textual description is a huge advantage as it eases non-technical stakeholders’ understanding. Using OPL, two model elements can be connected with words like “affect” or “contain” to describe their dependence [27]. OPCAT and OPCloud are tools to apply OPM [19,28] (p. 657).

Using the SYSMOD (System Modeling Process) methodology, a practitioner is also given a set of activities, which, however, do not have to be performed in a pre-set order [29]. The model created with SYSMOD is an abstract solution and only specified if technology-related decisions are met [21].

A rather new methodology is the Motego (Model-test-go) method [30] (p. 2). In this approach, the system is set up consisting of three types of structures: function, solution, and product. In their entirety, they consider the system requirements. The system’s functionality is displayed by several generic functions. These generic functions cannot be broken down further and constitute, e.g., energy-, data- or material-flows. Through the aggregation of elemental functions, it is possible to generate more complex behaviors for systems of different domains [31,32].

The SA (State Analysis) method is based on states, which represent a developing system at a given point in time. How one state is transferred to the next is described by the model [22]. SA will not be included in the assessment, as it focuses on intense software systems [23] (p. 164053).

There do exist other methodologies for MBSE, e.g., CONSENS and METUS [21] or MDDM [33] (p. 4) which will not be further discussed here. The described methodologies are evaluated.

3.2. Assessment of MBSE Methods

The assessment of the different MBSE methods is based on criteria partly taken from the FEMMP (Framework for the Evaluation of MBSE Methodologies for Practitioners) and complemented with new criteria for use in the context of battery development. The assessment is summarized in

Table 1. Assessment of MBSE approaches.

	Intuition	Reusability	Adaptability	Flexibility	Scalability	Comparability	Multi- Domain	Integrated Validation	Sources
ARCADIA									[19,34,35]
F4S4M & FAS									[21,24,25,36,37]
Harmony SE			n.a.						[8,22,38,39,40]
Magic/MBSE Grid		n.a.							[14,41,42]
Motego						n.a.			[15,30,31,32,43,44,45]
STRATA									[14,19,23,46]
OPM									[19,21,22,27,28]
OOSEM							n.a.		[22,23,25,41]
SYSMOD									[14,29,33,47]

Legend: No fit; Minor fit; Medium fit; Major fit; Full fit; n.a.: not available.

. Within the framework, criteria for areas like practicality, efficiency, and usability are checked. FEMMP aims to give the user an overview of the various methods for an easier comparison. Ranking the methods is not the aim of the framework. Criteria of the FEMMP, which will be partly adopted in the assessment, are intuition, reusability, tailoring, and scalability. Scalability labels, if a method can be applied to different large and complex systems and if it includes functions to manage complexity and keep transparency. Whether or to what extent a method allows customization is rated with tailoring. Reusability is evaluated by how well models or model elements can be reused in other projects, for example, through artifact libraries. Lastly, intuition assesses usability. In the original framework, different evaluation metrics for different criteria are used. To obtain a more coherent overview, this assessment will use only the metric of qualitative Harvey balls [33] (p. 1).

For this evaluation, tailoring will be split up into two separate criteria. Flexibility focuses on the procedure and how versatile it is. For example, different approaches like bottom-up or top-down can be allowed. Adaptability, on the other hand, refers to enabling subsequent changes within the model and the modeling process. It rates to what extent model artifacts can be modified and individualized. Complementary to flexibility, a new criterion can be evaluated. How well different models of the same system can be compared partly depends on how they have been accessed. The more versatile the approaches, the less easy the comparison of the resulting models. Traceability has also been considered as a criterion. It opens the option to follow the transition of stakeholder needs into requirements and further model elements within a model. The criterion was not applied in the assessment because most of the rated methods contain a kind of traceability, and a more detailed evaluation could not be made based on the information given.

Although MBSE, in general, aims at systems comprising several disciplines [14] (p. 25), the criterion multi-domain is added. This criterion assesses how well different disciplines can be integrated into the model, also for the sake of clarity. Integrated validation is also added as a new criterion in addition to the ones proposed by the FEMMP. It considers how well the model enables the checking of requirements through formal activities within the method or additional external ones. Integrated optimization into the method has also been viewed, as it would be an interesting feature. However, the criterion was dropped because too few methods included any optimization (-like) step. The results of the assessment are shown in Table 1. Due to a lack of reliable information, not all methods could be assessed against all criteria. Accordingly, no assessment is made for these points.

3.3. Conclusion of the Assessment

The evaluation carried out shows that there are already several methods within MBSE. Interestingly, the absolute differences within an evaluation criterion are often rather small. Among other things, this is due to the underlying modeling idea. Furthermore, it is noticeable that most methods do not integrate the validation of the requirements or are only rudimentary. Here, a deficit is detected regarding a requirement-conformal development. If the initial development goals, documented and communicated in the form of requirements, are not met, they must be corrected later in the development process. This correction in the form of engineering change requests (ECR) ties up both personnel and economic capacities. The consequences of ECRs can include increased costs, missed deadlines, or a lack of suitability for the target application [48]. Therefore, an early assessment of the development approaches and concepts is essential for successful project management.

4. MBSE for Battery Engineering

In the following, the specific application of MBSE in the context of battery system development is focused. Besides the challenges in battery modeling, an improved battery system model approach is presented, which is characterized by low complexity and the ability to handle low and highly detailed sub-models.

Simplified Domain-Based Systems Engineering Approach

As already elaborated in Section 3.1, a variety of modeling options exist in the field of MBSE with individual advantages and disadvantages. A decisive factor is the transfer of the requirements into product specifications and a resulting product concept. In research, the Motego modeling approach is, for example, used for a detailed system model development in the Model2Life research project [43]. In industry, the principle of modeling the maximum information content with the minimum effort is desirable. This leads to an ideal degree of fulfillment of the defined key performance indicators (KPI) for assessing the modeling approaches. In comparison to the already described Model2Life approach, a different more basic approach could handle complexity in an easier way for solving basic problems in industry. The overall challenge is modeling various levels of product structure and combining them with modeling functions on different domains such as mechanical, electrical, or thermal. The basis for the presented modeling approach is the product structure of a conventional traction battery for use in a BEV, as illustrated in Figure 3.

A battery system for electric vehicles can be divided into different domains, main components, and components ordered on three main levels. The differentiation between system, module, and cell level is currently the most widely used system architecture. Future concepts such as cell-to-x architectures are also applicable by skipping the module level and placing the existing module components in a higher or lower level of the product structure [49]. The different components realize the needed functions of energy storage and are linked with the properties of the structure elements. The battery cell, for example, combines a housing with anode, cathode, and electrolyte and has properties such as cell capacity or cell voltage. The properties themselves can be calculated by the function of higher or lower arranged product structure elements or could be fixed variables [50].

The general concept of the modeling approach is based on the challenge of complexity in information handling and the need for fast and well-founded concept development. The goal is to assess product concepts early with minimum effort. The model covers the common MBSE phases, such as requirements integration, concept definition, and validation. It enables a wide range of usage on different levels of detail, as further discussed in a specific example in Section 4. The proposed model structure for a battery development approach is illustrated in Figure 4.

The modeling approach consists of different levels with a defined structure for each product structure level. Two main structural elements define the framework. The product structure area defines the current components in scope and connects the components with the individual properties. Every component represents its own more detailed component level and could be detailed for a further degree of modeling. The properties represent the parameters of the present level in scope and define fixed variables or calculated values from lower or higher component levels. The defined requirements represent the basic product specifications of the elements derived from use cases. In the subsection of modeling functions, the functional structure of the battery is transferred to a modeling language. Therefore, specific domains are integrated into the system model. The current focus of the model is represented by the mechanical, electrical, and thermal domains. Future domains, such as cost, LCA, etc., could be easily added. Since some of the functions are repeated on every product structure level, global functions are defined and accessible through the model. Specific component functions are implemented and marked separately. Each of the modeling functions needs specific input and output parameters, which are connected through weighted interdependencies.

In comparison to most other MBSE approaches, a main characteristic of the presented modeling approach is the possibility of adding simplified as well as detailed models with an integrated validation loop to verify the fulfillment of the requirements. The aspect of simplification adds to the existing methods used in the industry. A risk associated with this approach is to oversimplify and by those neglecting important connections in between components, functions, and ultimately missing requirements. Summarized, this framework handles complexity through a defined structure of the needed modeling functions in addition to the product structure. It offers an efficient way to assess product concepts for multi-domain modeling questions. It increases the development speed for faster proofing of battery concepts with minimal effort. In the following chapter, the thermal domain of the model approach is described in detail.

5. Application for Thermal Modeling of a Single Battery Cell

To validate the idea of the methodological concept in a simulation pipeline, an analysis of the impact of different cooling strategies for a lithium-ion battery cell is performed. Therefore, a commercial cylindrical battery is chosen, characterized, and transferred into an electric-thermal model.

5.1. The Battery Modeling Framework in Usage

An example of a specific function on the cell level is the thermal simulation of a single cell based on load profiles resulting from the use case. The approach and the different steps are illustrated in Figure 5. The superior goal is to examine and simulate the thermal behavior of an existing battery cell and compare different cooling concepts for early concept decisions regarding thermal management to be implemented on the system level. To analyze the battery behavior, several models have to be set up and connected. For the different domains, these models can be implemented with individual complexity levels.

A simple model can be evaluated quite fast with minor restrictions on the quality of the results. The complex modeling approach at the other end of the modeling bandwidth is superior in the quality of the results but needs the most input parameters and the highest computational resources. The detailed modeling lies somewhere in between the simple and complex modeling. Comparisons with black-, grey- and white-box models can be applied as described in [52]. The simple modeling represents empirical models (black-box behavior). The detailed modeling can be compared with analytical models (grey-box behavior), whereas physical models are categorized as complex (white-box behavior). The information and parameters for the system modeling are shared within the battery modeling framework. The core of the battery modeling frameworks needs to know the product structure to connect the different models at the correct places with the correct parameters and evaluations.

According to the proposed framework, three major input sets are needed: the use case, the requirements, and the interfaces. Strictly speaking, use cases and interfaces can also be assigned to the requirements input set. However, for the sake of better understanding, the exact distinction is broken down here. The exact requirements for the product ‘battery system’ are derived from the case, which is primarily determined by the strategy of the planned development. In particular, the corporate strategy can serve as a source here. The interfaces can and must also be described in the form of requirements. However, the interfaces are also specified to the development by superordinate system levels. Under certain circumstances, the interfaces are interchangeable. To simplify the comparability of the modeling, the interfaces are managed as a separate set of requirements. According to the Automotive SPICE Model, the input sets of Use-Case and interfaces are on the SYS.1 (Requirements Elicitation) level, whereas the requirement set represents the SYS.2 (System Requirements Analysis) and SYS.3 (System Architectural Design) levels [53].

The Use-Case represents the superior sense for the concept evaluation; in this example, fast charging of a battery cell is considered. In a simplified approach, a constant charging rate of 2 C for the state-of-charge (SOC) ranging from 10% to 80% is assumed. This is rather high, especially for the higher SOC. The input set of requirements defines which functions must be fulfilled by the concept and to what extent. An example excerpt of the requirements is given in

Table 2. Different input sets for the battery modeling framework.

Input Set	ID	Description	Explanation	Source
Use-Case	U.01	Simple fast charging is considered: 2 C charging rate; SOC [10%; 80%].	A first indication of charging behavior is needed.	Stakeholder
	U.xx	…	…	…
Requirements	R.01	The maximum temperature in the battery cell must not exceed 60 °C.	The cell manufacturer defines a maximum working temperature.	Datasheet [55]
	R.02	The maximum temperature spread within the battery cell must not exceed 5 °C at any time of charging.	A high-temperature gradient within a battery cell supports accelerated aging. This mechanism shall be limited [56].	Following [57]
	R.xx	…	…	…
Interfaces	I.01	The thermal management provides a fluid at 20 °C.		Stakeholder
	I.xx	…	…	…

. The later concept results must implement the requirements. Interfaces describe any connections of the system to the surroundings. These can be turnovers of energy, substance, or signal [54].

To close the framework approach, one or more battery concepts are developed and evaluated. The concepts are developed based on simulating the tasks given by the input sets in the battery modeling framework core. These concepts are challenged and validated against the initial requirements set. Only concepts with fulfillment can be considered for the following development stages. If there are multiple concepts with fulfillment of the requirements, an assessment within the concept pool can be included to rank the concepts according to the superior development goals. For ranking, general or specific methodologies can be used.

5.2. The Simulation Pipeline

The lithium-ion cell chosen is the cylindrical LG INR21700-M50 with a nominal energy content of 18.2 Wh [55]. An electrical characterization is performed at an environmental temperature of 20 °C in a temperature chamber with three battery cells. The open circuit voltage (OCV) curve and impedance are evaluated. For the impedance measurement, a multisine potentiostatic electrochemical impedance spectroscopy with a frequency range from 10 mHz to 10 kHz with ten frequencies per decade is chosen. The measurements have been conducted at ten different OCVs. For the usage in an equivalent circuit model, the parameters for the circuit are fitted with the Python package impedance [58]. The fitting is performed for each evaluated SOC. As an electrical model, a second-order Thevenin model is chosen which consists of one resistor R₀ and two resistance capacitance (RC) couples [59]. The first resistor R₀ and R₁C₁ couple simulate fast dynamics like the charging transfer, whereas the R₂C₂ couple represents slow dynamics like diffusion in the materials [60].

For the thermal simulation, three different cooling strategies are chosen: cooling via the cell bottom (bottom cooling), side wall cooling, and immersion cooling. The models have been set up in COMSOL Multiphysics 5.6. To evaluate the heat generation in the cell, the irreversible losses across the resistances in the equivalent circuits are used. The communication between the different models is represented by parameters already described above. Some examples of the different input and output parameters for these models are shown in

Table 3. Example design parameters within the battery modeling framework.

Domain	Model	Input Parameters	Output Parameters
All	Global	diameter_cell = 18 mm capacity_cell = 4800 Ah C-rate = 2 h−1 SOC = [10%; 80%] …	n.a.
Electrical	ECM parametrization	Z {SOC; f} @ 25 °C	R0 {SOC} R1 {SOC} C1 {SOC} R2 {SOC} C2 {SOC}
Electrical	Local ECM	Output ECM parametrization …	heat_generation {t}
Thermal	3D FEM thermal	heat_generation {t} …	max_temperature {t} min_temperature {t} avg_temperature {t} …
Mechanical	Geometry	Material parameters …	thermal_conductivity_axial thermal_conductivity_radial …

.

To enable the thermal simulation, not only the electrical behavior has to be known. The mechanical design of the battery cell is crucial to evaluate the heat flows through the different components. In this example, a simplified geometrical model was used to reduce the calculation effort. As a simplification, the jelly roll is considered as one component. To take the different thermal conductivities in radial and axial directions into account, an anisotropic behavior is assumed. Thus, the real behavior can be approximated by the anode, cathode, and separator layers without having to model the winding of the cell exactly. For the approximation of the conductivities, the materials of the cell winding are considered.

As a result, it is found that under the given conditions, immersion cooling allows the smallest temperature difference in the cells. This is in line with results from the literature [61]. However, a practical validation of the concretely calculated temperature levels is still pending. In the context of the methodology presented here, it can be stated that all three thermal concepts investigated can satisfy the initial requirements. Immersion cooling stands out with the best temperature homogeneity, but other system evaluations are not considered at this point and are consequently missing in the evaluation. An example of this is potential complications at the system level in the form of increased tightness requirements or thermal management costs. These are necessary extensions of the battery modeling framework. The basic workflow could be shown methodically and demonstrated in a simulation workflow.

6. Conclusions and Outlook

This paper presented a new approach to the modeling of battery systems, with a particular focus on streamlining the complex and multi-domain process involved in battery development. The core is the battery modeling framework, which links the various and domain-specific models. This framework addresses the intricate requirements of battery systems and allows for faster, iterative development cycles, essential in today’s rapidly evolving electric mobility landscape. A basic knowledge of the system architecture of battery systems is necessary for the linkage. This foundational knowledge has been presented within the framework. However, this is known and presented as a foundation for the battery framework. This knowledge can be implemented in simulation software packages to ease their use in future developments. At this point of technological readiness, the fact is exploited that battery systems have already been developed in many forms and that further developments and optimizations are now primarily the focus of the development tasks. To accommodate the desire for rapid and iterative developments, it is possible to go to different depths of detail in modeling sub-questions.

The battery modeling framework presented in this paper advances the state of the art in MBSE and automotive development by enabling a wide variance in model usage. The framework supports interchangeable models, allowing for more detailed simulations as the development cycle progresses. This flexibility ensures that increasingly sophisticated models can be utilized without disrupting workflow. Additionally, the approach enhances the speed and efficiency of requirements definition, facilitating rapid construction and comparison of various concepts. This capability helps to reduce potentially costly late-stage changes, as highlighted by the expert interviews (see Figure 2).

At this point, the basic methodological framework has been built, and its functionality has been demonstrated. However, further sub-models still need to be adapted to enable more complex analyses, e.g., of costs, sustainability assessments, or battery safety evaluation. Detailing and adding further models are planned. The inclusion of models with a focus on electrochemical battery behavior will enable the closed-loop development from battery material to battery system. An arising challenge lies in the efforts of calculating these large models. Simplifications will be necessary. The extension of the battery modeling framework to sodium-ion batteries is being undertaken in a newly initiated research project (grant number EFRE-20800353). This will facilitate the synchronous comparison of different cell chemistries within one modeling system.