WO2008034499A1

WO2008034499A1 - A device for and a method of performing a coupled simulation of a physical structure described by several separate models

Info

Publication number: WO2008034499A1
Application number: PCT/EP2007/007185
Authority: WO
Inventors: Wolfgang Puntigam
Original assignee: Kompetenzzentrum - Das Virtuelle Fahrzeug Forschungsgesellschaft Mbh
Priority date: 2006-09-21
Filing date: 2007-08-14
Publication date: 2008-03-27

Abstract

A device (100) for performing an analysis of a physical structure, wherein the device (100) comprises a plurality of analysis units (101 to 105) each adapted for analyzing an assigned one of a plurality of virtual segments in which the physical structure is segmented, and a synchronisation unit (111) for synchronising the analyses of the plurality of analysis units (101 to 105) under consideration of physical frame conditions for the physical structure.

Description

A DEVICE FOR AND A METHOD OF PERFORMING A COUPLED SIMULATION OF A PHYSICAL STRUCTURE DESCRIBED BY SEVERAL SEPARATE MODELS

5 The invention relates to a device for performing an analysis of a physical structure.

Beyond this, the invention relates to a method of performing an analysis of a physical structure.

Moreover, the invention relates to a program element. 0 Furthermore, the invention relates to a computer-readable medium/

Beyond this, the invention relates to a method of use.

The Computational Fluid Dynamics (CFD) method is a powerful tool5 for analyzing problems in fluid dynamics and may be helpful in product development and failure analysis.

Yevgen Shumeyko, Oleksiy Anfoshkiv, Youen Puillandre, Heinz Peter Berg, (2006) "Simulation eines Motorwarmlaufs im neuen europaischen Fahrzyklus (NEFZ)", Warmemanagement des 0 Kraftfahrzeuges, June, 1 and 2, 2006, Berlin, ISBN-10, 3-8169-2651-7 pages 29 to 37 discloses coupling of different simulation methods (Flowmaster and AVL-CRUISE) for modelling engine warm up in NEFZ.

W.Tegethoff, C. Correla, R. Kossel, M. Bodmann, N. Lemke, J. Kόhler: Co-Simulation und Sprachstanardisierung am Beispiel des 5 Warmemanagements, Warmemanagement des Kraftfahrzeuges, June, 1 and 2, 2006, Berlin, ISBN-10, 3-8169-2651-7 pages 231 to 242 discloses methods of modelling and simulation of large complex systems constituted by partial systems.

However, conventional simulation schemes for simulating a 0 technical apparatus or system may lack sufficient efficiency.

It is an object of the invention to provide an efficient analysis of a physical structure. In order to achieve the object defined above, a device for performing an analysis of a physical structure, a method of performing an analysis of a physical structure, a program element, a computer-readable medium, and a method of using a device for performing a computational fluid dynamics analysis of the physical structure according to the independent claims are provided.

According to an exemplary embodiment of the invention, a device for performing an analysis of a physical structure is provided, wherein the device comprises a plurality of analysis units each adapted for analyzing an assigned one of a plurality of virtual segments in which the physical structure is segmented, and a synchronisation unit for synchronising the analyses of the plurality of analysis units under consideration of physical frame conditions for the physical structure.

According to another exemplary embodiment of the invention, a method of performing an analysis of a physical structure is provided, wherein the method comprises analyzing a plurality of virtual segments, in which the physical structure is segmented, by a plurality of analysis procedures each analysing an assigned one of the plurality of virtual segments, and synchronising the analyses of the plurality of analysis procedures under consideration of physical frame conditions for the physical structure.

According to yet another exemplary embodiment of the invention, a computer-readable medium is provided, in which a computer program of performing an analysis of a physical structure is stored which, when being executed by a processor, is adapted to control or carry out a method having the above mentioned features.

According to still another exemplary embodiment of the invention, a program element of performing an analysis of a physical structure is provided, which program element, when being executed by a processor, is adapted to control or carry out a method having the above mentioned features.

According to a further exemplary embodiment of the invention, a device having the above-mentioned features is used for performing a computational fluid dynamics (CFD) analysis of the physical structure.

Data processing for simulation purposes which may be performed according to embodiments of the invention can be realized by a computer program, that is by software, or by using one or more special electronic optimization circuits, that is in hardware, or in hybrid form, that is by means of software components and hardware components.

The term "physical structure" may particularly denote any object (particularly any technical apparatus, member, or a portion thereof) in the real world which may be under development or analysis and shall therefore be investigated by a simulation analysis. Thus, during the theoretical analysis (which may include tool like a finite element analysis and/or computational fluid dynamics), a virtual pendent of the physical structure may be investigated. An example of such a physical structure may be a vehicle under development, more particularly a car, or a liquid cycle sub-system of a car. The term "computational fluid dynamics" (CFD) may particularly denote the technical field of determining a numerical solution to governing equations of fluid flow whilst advancing the solution through space or time to obtain a numerical description of the complete flow field of interest. This may include the simulation of flows, such as the flow of air around a moving car or plane. Computational fluid dynamics (CFD) may denote the use of computers to analyse problems in fluid dynamics.

The term "finite element analysis" may particularly denote a computer-based procedure (such a computer may comprise a processor having processing capabilities, a memory for storing information or data, and/or an input/output interface for exchanging data with a connected instance) using a finite element (FE) method. Finite element analysis (FEA) or finite element method (FEM) may denote a numerical technique for solution of boundary-value problems, particularly for use in structural analysis. In its application, the object or system may be represented by a geometrically similar model formed by multiple, linked, simplified representations of discrete regions, i.e., finite elements.

The term "analysis unit" may particularly denote any component capable of performing a computational, numerical, mathematical and/or theoretical analysis of a functional unit of the physical structure. Such analysis unit may be a conventional computer on which an appropriate software is running. For example, such an analysis may be a computer- aided engineering (CAE) or computer-aided optimization procedure, for instance using a finite element method or a CFD method. The analysis units may operate essentially independently or autonomously, however may be centrally controlled by a synchronisation unit synchronising the individual calculation strategies of the analysis units, thereby ensuring that the individual analysis units do not run to a meaningless, non- physical, purely mathematical result.

The term "synchronisation unit" may particularly denote a central control instance, like a server computer controlling a plurality of clients (or a master controlling a plurality of slaves), wherein the synchronisation unit may manage or coordinates the functions of the individual analysis units, particularly to bring the results (and/or intermediate results) of the individual analysis unit in conformity. Such a synchronisation unit may therefore control the complex system of the physical structure, wherein parts thereof are analysed individually, separately and/or autonomously by the corresponding ones of the analysis units.

The term "physical frame conditions" may particularly denote boundary conditions or necessary requirements which have to be fulfilled when defining initial states for the analysis and/or when evaluating the physical or real relevance of results obtained by a partial analysis, or by an entire analysis. Examples for such physical frame conditions are natural laws, like the conservation of energy, the conservation of a momentum or the conservation of torque. Also compliance of a timing, compliance with the Pauli principle, or compliance with mathematical frame conditions (like the stability of mathematical solutions) may be covered by this term.

The term "time increment" of the analysis may particularly denote a fixed period of time - time increment - which divides the time axis in defined discrete time points. The difference between two time points is called time increment. Here fixed and variable time increments can be distinguished. Fixed time increments always have the same value in seconds over the time axis. Variable time increments have different values in seconds over time domain. Values of variable time increments can be controlled over so called time increment algorithms. Time increment algorithms are controlling the value of time increments depending on the physical behaviour of the simulation models. So the value of the time increment vary during the simulation. Small time increments are used for fast changes of physical values during the simulation to ensure a stable simulation. Small time steps are time consuming. Big time increments are used for low changes in physical values to save simulation time.

According to an exemplary embodiment of the invention, a complex physical structure to be analysed theoretically is separated virtually (that is to say not physically, but as a basis for a mental/computational exercise) into individual components or functional portions. Then, each of the functional portions may be investigated individually by one of the individual analysis tools with a reasonable computational burden, and thus sufficiently fast. By taking this measure, each specific component may be analysed with the best possible analysis tool selectively for this component. The then received "mosaic" parts indicative of the function of the respective functional group of the physical structure which are received from the individual analysis tools may then be assembled by the synchronisation unit to obtain an overview, taking into account "global" physical frame conditions which may not be necessarily considered by the individual analysis tools. Therefore, the synchronisation may check the results with regard to physical relevance and/or may monitor the exchange of data between the plurality of analysis tools with regard to compliance with natural laws. Therefore, artificial, purely mathematical results without physical meaning may be recognized or eliminated or prevented at an early stage of the analysis, thereby increasing reliability of the results and ensuring that computational resources are used efficiently. Thus, a device according to an exemplary embodiment of the invention may allow to obtain theoretical or numerical simulation results which are a proper fingerprint of the actual technical physical system.

Different software modules may be used in different development departments of a company, for instance for developing an automobile. For example, it might be of interest to study a transient warm-up characteristics of such a car, in which a plurality of different functional components interact. Exemplary embodiments of the invention allow different individual software components to each perform calculations with regard to a specific functional component of the automobile to be developed. For each software component, a used algorithm may be selectively matched to the requirements of the respective functional component. Managed by a synchronisation unit, the software component may communicate with one another, for instance using CORBA or any other appropriate platform. Therefore, a data exchange between different programs running on different simulation machines may be performed in an intelligent manner, taking into account global conservation laws. Such conservation laws may allow a conformity with energy conservation requirements, mass conservation requirements or the agreement with coupling frame conditions. When the synchronisation unit detects a violation of such a physical frame condition, it takes appropriate measures to modify the individual calculation schemes to be brought in accordance to one another, thereby ensuring that simulation results are in accordance with natural laws.

For instance, it is possible that the time step width of the individual analysis components is adjusted so that physically reliable results may be obtained.

For example, for studying the one-dimensional heat conduction characteristics in a rod, the heating characteristics in the rod may be analysed by separating the rod virtually into a left-hand rod half and a right-hand rod half. Both rod halves may then be analysed in separate or individual simulation programs. When combining the individual results, the final result can be brought in accordance with the actual physical system, namely one common rod, wherein the results may be verified to be or brought to be in accordance with physical laws. Therefore, parameters of the analysis, for instance a time step width may be monitored or adjusted to bring the results in accordance with physical frame conditions. Coming back to the example with the rod, the principle of energy conservation and the fundamental theorems of thermodynamics must be fulfilled when considering the simulation results regarding both rod halves as a whole. If these frame conditions are violated (wherein small deviations less than a threshold value might be accepted according to exemplary embodiments of the invention), measures may be taken to eliminate the violation, for instance by formulating restrictions or boundary conditions which have to be complied with. Particularly, a data exchange between the different segments of such a simulation of the physical system may be brought in accordance with the physical frame conditions. For example, synchronisation commands or instructions may be supplied by the synchronisation unit to thereby bring the individual analysis units in accordance to one another. By synchronising the data exchange and the function of the individual analysis units, instabilities of the calculations (for instance instable solutions of differential equations) may be prevented, detected early and/or may be eliminated, and/or the compliance with natural laws may be guaranteed. Therefore, when individual analysis units exchange input/output parameters, a program control may be performed (for instance a time step width control), so that natural laws are fulfilled by the simulation, and the model will be more stable from a numerical point of view. For example, five different components of a physical structure like a car can be analyzed by calculation on individual computers which may be operated by individual experts. Notice may then be given to a central server about individual results or data exchange between the individual computers, so that a modification of one individual component may be brought to the attention of the central server which may be then capable of managing the entire model.

Therefore, a coordinating computer may be provided which provides a synchronisation and controls all the models, thereby bringing the individual components of the entire physical structure in accordance to one another. Thus, a distributed technical analysis may be made possible, wherein a central monitoring of the analysis may prevent contractive results.

Exemplary embodiments of the invention may be particularly applied advantageously in thermo dynamics and fluid dynamics simulation systems, coupling zero-dimensional, one-dimensional and three-dimensional simulation routines.

Particularly, a method for coupling of zero-dimensional, one- dimensional and three-dimensional simulation models may be provided. Embodiments of the invention may provide an efficient method for coupling individual simulation programs running on different computational architectures with different operation systems in a transient manner. The data exchange may be controlled to be time- synchronous, for instance in order to be capable of mapping warm-up procedures of complex technical systems, or the like. Therefore, interface technologies and middleware concepts have been developed. Derived from such investigations and based on the requirements of the simulation programs, a method for simulating complex physical models is provided. The method is based on the recognition that technical systems may be distributed into partitioned sub-systems, which exchange data via a defined physical interface. Each individual model (simulation program) may be covered with a first communication layer which ensures the communication. These communication layers have already been implemented in PYTHON (which is a script language). In a next step, these communication layers have been extended by a respective control unit which controls the individual programs with chronological synchronism (or in a time synchronous manner). These control units may overtake the transient data exchange and may be responsible for the transient data exchange and for the synchronisation of the individual programs. With such an architecture, none of the programs has the absolute control, but the interface itself manages the data between equal participants of an entire simulation. By such an interface design, the method may be made independent of the individual simulation programs and models, thereby increasing the flexibility of the system and the potential fields of application. In a further procedure, an entire model of a vehicle has been assembled, and the individual couplings have been analysed in more detail. Particularly, the time control and the influence of individual time step width in the individual models has been studied in more detail. This coupling opportunity has been applied to an engine portion of a car, in order to investigate the temperature distribution in the engine compartment due to the heat insert of the cooling packet. With this application scenario, questions related to the temperature management of the cooling system and the engine compartment fluid dynamics can be answered. Taking this measure, it is also possible to realistically map fuel cooler, oil cooler, steering cooler and the interaction of these components into a meaningful virtual equivalent.

Another field of application of the coupling is the simulation of the entire car. In such a scenario, an entire model may be constituted by partial models of KULI, CRUISE and BOOST. KULI is a simulation software for calculating cooling systems in vehicles. CRUISE is a simulation tool for vehicle design. CRUISE may be used to perform vehicle simulation and power train analyses to develop or optimize low emission engines, reliable power trains and sophisticated control systems of engines, cooling and transmission systems. BOOST is a software tool for the simulation of engine processes. The transient warm-up characteristics of an engine and the operation of fluids, as well as their feedback to fuel consumption and emissions may be investigated in this context.

Next, further exemplary embodiments of the device for performing an analysis of a physical structure will be explained. However, these embodiments also apply to the methods, to the program element and to the computer-readable medium.

The synchronisation unit may be adapted for synchronising the analyses of the plurality of analysis units under consideration of at least one law of nature as the physical frame condition. A law of nature may be a scientific generalisation based on empirical observations, which is widely accepted. Laws of nature are conclusions drawn from or hypothesis confirmed by scientific experiments. Examples for laws of nature are Newton's Theories of Classical Mechanics, Einstein's Theory of Relativity, Boyle's Law of Gases, Conservation Laws, Ohm's Laws, the fundamental Laws of Thermodynamics, etc.

The synchronisation unit may be adapted for synchronising the analyses of the plurality of analysis units under consideration of at least one law of conservation as the physical frame conditions. Generally accepted conservation laws are the conservation of energy, the conservation of linear momentum, the conservation of angular momentum, the conservation of electric charge, the conservation of mass. The synchronisation unit may be adapted for synchronising the analyses of the plurality of analysis units by adjusting a time increment for the analyses in accordance with the physical frame conditions for the physical structure. Such a time increment may define a time step width (and therefore the accuracy) of a numerical analysis, and may be a basic input parameter for adjusting a numerical procedure for solving a differential equation.

The synchronisation unit may be adapted for synchronising a data exchange between the plurality of analysis units in accordance with the physical frame conditions for the physical structure. Therefore, when the individual analysis units exchange input/output parameters, the synchronisation unit may verify whether these parameters are in accordance with the physical laws. Thus, very early during the numerical analysis, the synchronisation unit may avoid non-physical calculations and may force an analysis towards a more realistic direction. The device may comprise a segmentation unit for virtually segmenting the physical structure into the plurality of virtual segments. Such a segmentation unit may segment a physical structure, for instance a car, into different functional components, which may be interconnected by virtual interfaces. For implementing such a segmentation unit, expert knowledge, empiric knowledge, or artificial intelligence (for instance fuzzy logic, a neural network, etc.) may be used.

The segmentation unit may be adapted for virtually segmenting the physical structure into the plurality of virtual segments so that each of the plurality of virtual segments comprises one or more elements. For example, these elements may be finite elements when the analysis of a specific one of the analysis units performs a finite analysis unit.

The segmentation unit may be adapted for virtually segmenting the physical structure into the plurality of virtual segments so that the one or more elements of each of the plurality of virtual segments form one of the group consisting of a zero-dimensional space, a one- dimensional space, a two-dimensional space, and a three-dimensional space. A "zero-dimensional space" may particularly specify a critical point (for instance a welding spot) of the physical structure. A "one- dimensional space" may describe physical processes occurring along one direction, for instance a fluid flow along a (straight) line. A "two- dimensional space" may describe a planar or a two-dimensionally bound issue, for example the outer surface of a car for aerodynamics investigations. A "three-dimensional space" may describe a volumetric issue. More particularly, the segmentation unit may be adapted for virtually segmenting the physical structure into a first virtual segment forming a zero-dimensional space, a second virtual segment forming a one-dimensional space, and a third virtual segment forming a three- dimensional space. It has been recognized that such a segmentation is particularly advantageous for describing an automobile, more particularly a thermodynamic system of an automobile.

The first virtual segment may be indicative of at least one of the group consisting of a thermal behaviour of an engine of a vehicle, a thermal behaviour of a drive section of a vehicle, a thermal behaviour of a fuel guide of a vehicle, and a thermal behaviour of an exhaust system of a vehicle. The second virtual segment may be indicative of a thermal behaviour of a fluidic connection or a fluidic network of a vehicle, and the third virtual segment may be indicative of a thermal behaviour of a cooling system of a vehicle, and a thermal behaviour of an engine compartment of a vehicle.

The synchronisation unit may be adapted for synchronising a timing of the analyses of the plurality of analysis units. Therefore, artefacts resulting from an insufficient time coordination of the individual components may be avoided. The synchronisation unit may be adapted for transient data exchange between the plurality of analysis units. For instance, when a portion of a physical system has been analysed, the results of this system may be supplied as input parameters or feedback parameters to other components of the analysis system. When the individual calculation units exchange such data, the entire functionality of the physical system may be described precisely.

The synchronisation unit may comprise a plurality of synchronisation sub-units each of which being assigned to one of the plurality of analysis units, wherein the plurality of synchronisation sub- units are adapted for cooperating to synchronise the analyses of the plurality of analysis units. Therefore, even in the synchronisation unit, distributed components may be provided which harmonise or coordinate the entire calculation but are assigned to a specific one of units.

The device may comprise a definition unit for defining at least one virtual interface for coupling the plurality of virtual segments in a manner to simulate mechanical properties of the physical structure. Therefore, the interaction of the individual components or sections may be simulated using interfaces, via which different coupling parameters as input and/or output parameters may be exchanged. The plurality of analysis units may be adapted for performing the analyses with different levels of computational burden and/or with different levels of detail. For example, the less complex one of the segments is, or the fewer components are included in a segment, the lower may be the effort for the analysis. On the other hand, the more important a specific portion is for the entire system, the more detailed may be the analysis. For instance, when one component of an entire system has a strong influence on a large number of the other components, the corresponding analysis may be more detailed than for systems which do not have a significant influence on the entire system. The device may be adapted for performing a numerical analysis, particularly a computational fluid dynamics analysis, of a physical structure. However, the kind of analysis performed in the individual analysis units may differ. For instance, it is possible that one of the analysis units performs a CFD analysis, whereas another one of the analysis units performs a finite element analysis, and a third one performs a Monte Carlo simulation.

In the following, further exemplary embodiments of the method of using a device for performing a computational fluid dynamics analysis of the physical structure will be explained. However, these embodiments also apply to the device, to the method of performing an analysis of a physical structure, and to the program element and to the computer- readable medium.

The method may comprise performing the computational fluid dynamics analysis of the physical structure to simulate a time-dependent behaviour of the physical structure. For instance, a warm-up procedure of an engine may be modelled. The warm-up procedure may be related to at least one of the group consisting of an engine compartment under the influence of waste heat of a cooling unit, a fuel cooling unit, an oil cooling unit, and a cooling unit for a guiding unit. Particularly, the computational fluid dynamics analysis of the physical structure may simulate a vehicle as the physical structure. However, examples for such a vehicle may be cars, ships, planes, cycles, motorcycles, or trains. The simulation of the vehicle may comprise a simulation of a warm-up procedure, that is to say of a heating or cooling characteristics of components of such a system, for example during normal use. Particularly, the warm-up procedure may be related to at least one of the group consisting of a warm-up characteristic of an engine of the vehicle, a warm-up characteristic of an operating liquid of an engine of the vehicle, an influence of the warm-up characteristic to a fuel consumption of the vehicle, and an influence of the warm-up characteristic to emissions of the vehicle.

However, these are only exemplary embodiments, and any other fields of application may be used to properly simulate a distributed system. For examples, a welding spot analysis or crash simulations are other exemplary fields of application of embodiments of the invention.

The aspects defined above and further aspects of the invention are apparent from the examples of embodiment to be described hereinafter and are explained with reference to these examples of embodiment.

The invention will be described in more detail hereinafter with reference to examples of embodiment but to which the invention is not limited.

Fig. 1 illustrates a device for performing an analysis of a physical structure according to an exemplary embodiment of the invention. Fig. 2 illustrates a data processing system which may be implemented in a system for performing an analysis of a physical structure according to exemplary embodiments of the invention.

Fig. 3 illustrates main parts influencing a thermal system.

Fig. 4 illustrates a simplified integrated simulation model, which comprises different partial models.

Fig. 5 illustrates partial models combined to an integrated thermal management model (comprehensive model).

Fig. 6 illustrates zooming between different detailed modelling levels of physical models.

Fig. 7 illustrates a physical interface of a simplified integrated thermal management model.

Fig. 8 illustrates partial models as objects with input and output features (in and out parameters).

Fig. 9 illustrates input parameters which are also called data sinks and output parameters which are also called data sources.

Fig. 10 illustrates an integration layer as a common communication basis for different simulation programs on different computer platforms and operating units.

Fig. 11 illustrates that every simulation tool can be regarded as an integrator which solves differential equations, wherein these integrators are synchronised by the communication layer.

Fig. 12 illustrates synchronisation of two programs with different time step length in a first step.

Fig. 13 illustrates synchronisation of two programs with different time step length in a second step.

Fig. 14 illustrates synchronisation of two different integrators.

Fig. 15 illustrates explicit and implicit synchronisation techniques for coupling of two simulation models.

Fig. 16 illustrates explicit time synchronisation with a predictor step.

Fig. 17 illustrates interpolation of output vales (average value between 2 time steps, n and n+1) from program 2 to be used as boundary condition (input values) for program 1.

Fig. 18 illustrates that last parameter information is handled from program 2 over to program 1, because no average value can be built.

Fig. 19 illustrates a KULI model of an air path.

Fig. 20 illustrates KULI inner circuits: AC circuit and water circuit.

Fig. 21 illustrates a CRUISE Model of a power train. Fig. 22 illustrates a description of a physical interface between KULI and CRUISE in the context of a data exchange.

Fig. 23 illustrates an interaction between the power train and the AC circuit. After 20 sec the AC system is switched on (see curve car velocity). In the zoom window a decreasing acceleration (two different speed gradients) can be seen, caused by the activated AC system)

Fig. 24 illustrates an interaction between the power train and the AC circuit. After 20 sec the AC system is switched on (the curve shows an engine torque and an engine speed, respectively).

Fig. 25 illustrates a behaviour of the input and output enthalpy of the AC compressor. After 20 sec, the climate system is activated.

Fig. 26 illustrates a temperature distribution over the simulation time. After 20 sec a temperature increase can be seen, caused by the activated AC system.

Fig. 27 illustrates a difference between monolithic and partitioned methods for modelling entire vehicle systems.

Fig. 28 illustrates a partition of the system "entire vehicle" in individual partial models, wherein the partial models cooling package, engine, power train and thermal network are correlated via their input and output relations.

Fig. 29 illustrates the partial model engine.

Fig. 30 illustrates the partial model power train. Fig. 31 illustrates the partial model thermal network.

Fig. 32 illustrates the partial model cooling package.

Fig. 33 illustrates a sequence of the time integration loop and the inner interactions.

Fig. 34 illustrates a layer model of the independent co-simulation environment.

Fig. 35 illustrates a parallel coupling of two partial models.

Fig. 36 illustrates a sequential coupling of two partial models.

Fig. 37 illustrates a direct data exchange between the partial models.

Fig. 38 illustrates a power train mapped in a simulation program AVL CRUISE.

Fig. 39 illustrates a model of the engine in the simulation programming AVL BOOST for engine process calculation.

Fig. 40 illustrates a model of the thermal network with the simulation tool Matlab/Simulink.

Fig. 41 illustrates a model of the cooling package with the cooling system simulation programming KULI. Fig. 42 to Fig. 45 show diagrams illustrating a transient simulation of the engine warm-up behaviour.

Fig. 46 illustrates the global energy balance and the internal energy flows of the entire system of the vehicle from a thermodynamic point of view.

Fig. 47 illustrates the power balance for the charge change process calculation.

Fig. 48 illustrates the power balance for the thermal network.

Fig. 49 illustrates the global power balance after 300 seconds simulation time.

Fig. 50 illustrates a shift of the information flow in case of a parallel coupling of two partial models with a coupling time step of 0.1 seconds, particularly with an excerpt between 119 seconds and 125 seconds.

Fig. 51 illustrates a local power balance of BOOST of a coupled simulation.

Fig. 52 illustrates a local power balance of CRUISE of a coupled simulation.

Fig. 53 illustrates the information flow of the heat flow in case of a staggered coupling of two partial models and a coupling time step width of one second, showing an excerpt between 120 seconds and 170 seconds. Fig. 54 to Fig. 56 show diagrams illustrating coupled simulation models.

Fig. 57 illustrates limits of the system of the entire vehicle.

The illustration in the drawing is schematically. In different drawings, similar or identical elements are provided with the same reference signs. In the following, referring to Fig. 1, a system 100 for performing an analysis of a physical structure, namely of a car, according to an exemplary embodiment of the invention will be explained.

The system 100 comprises a plurality of individually operated analysis computers which are denoted with reference numerals 101 to 105. Each of the analysis computers 101 to 105 operates autonomously and analyses an assigned one of a plurality of virtual segments in which the physical structure is virtually segmented.

Experts are capable of bi-directionally communicating with the plurality of analysis units 101 to 105 via user input/output interfaces 106 to 110. The input/output units 106 to 110 each comprise a display unit and may therefore be denoted as a graphical user interface (GUI). Such a display unit may be a plasma device, an LCD device, or even a cathode ray tube. Furthermore, input elements are provided with each of the interface units 106 to 110, for instance a keypad, a joystick, a trackball, a touch screen or even a microphone of a voice recognition system.

The system 100 further comprises a server computer which is also denoted as a synchronisation unit 111 and which is adapted for a bidirectional communication with each of the analysis units 101 to 105. The synchronisation unit 111 synchronises the analysis of the plurality of analysis units 101 to 105 under consideration of physical frame conditions for the physical structure, for instance conservation of mass, energy, momentum, etc.

A segmentation unit 112 is provided for virtually segmenting the physical structure and the plurality of virtual segments. In other words, the segmenting unit 112 which may be also controlled by a human operator may be supplied with information indicative of the physical system to be analysed (for instance a car prototype) and may decompose this physical system into a plurality of functionally separated components. This information may then be supplied to the synchronisation unit 111, and/or to the analysis units 101 to 105.

An input/output unit 113 is provided and has a capability similar to that of the components 106 to 110. The input/output unit 113 allows an operator of the synchronisation unit 111 to coordinate the functionality of the individual analysis units 101, 105, assisted by the synchronisation unit 101 which has a corresponding algorithm stored therein.

A database 114 is furthermore connected to the synchronisation unit 111 and allows the storage of data with regard to the physical structure, expert rules, empiric knowledge, algorithms and/or software components, etc. Particularly, the database unit 114 may store data related to physical frame conditions like natural laws, and routines allowing to test whether specific analysis results are in compliance with such natural laws.

An optional definition unit 115 is foreseen for defining interface couplings between the plurality of virtual segments in a manner to simulate mechanical properties of the physical structure. In other words, the definition unit 115 cares about the exchange of input/output data between the units 101 to 105, thereby coordinating the interaction between the units 101 to 105. The data processing device 200 depicted in Fig. 2 is an example for a possible hardware configuration of any one of units 101 to 111, 113.

The data processing device 200 comprises a central processing unit (CPU) 201 connected to a memory 202 for storing data related to the performed analysis of the physical structure. The data processor 201 may be connected to other components of the system 100, as indicated by reference numeral 205. The data processor 201 may furthermore be connected to a display device 203, for example a computer monitor, for displaying information related to the performance of the data processor 201. An operator or user may interact with the data processor 201 via a keyboard 204 and/or other output devices, which are not depicted in Fig. 2. Furthermore, via a bus system 205, it is also possible to connect the processor 201 to other components. In the following, a transient co-Simulation of comprehensive vehicle models by time dependent coupling according to an exemplary embodiment of the invention will be explained referring to Fig. 3 to Fig. 26.

Recent trends in computer aided engineering (CAE) and optimization (CAO), seem to be introducing more and more simulation techniques based upon the combination of two or more simulation tools in order to accomplish a common task. One factor that led to this co- simulation trend is the ongoing development of computational resources which enable the working-together of different simulation tools which are of themselves usually complex enough and finishing the designated tasks within acceptable time limits. This description deals on the one hand with an independent coupling integration approach and on the other hand with some basic assumptions regarding the synchronisation in the time domain which form the very basics of each co-simulation process. The development of coupled simulation models gained an impetus in simulation processes as applied in automotive industry. It is the aim of this description to give answers not only to the behaviour of particular subsystems but also to describe the behaviour of the system as a whole, taking into account all mutual dependencies between those subsystems. For the purposes of this analysis, the simulation solvers can be roughly divided into transient and stationary ones. Steady state simulation processes will not be further considered within the time domain synchronisation analysis since they can be easily coupled at any time of simulation when needed for any available input data. Among the solvers used for transient processes, a term that describes the progressive simulation processes in time, it is possible to distinguish the processes based upon a predefined, fixed time step and those with variable time steps. One can further divide variable time step systems into those where the time step length being one of the input parameters, i.e. pre-set from 'outside', and into those where the time step length is a function of the system input vector and the system state vector, i.e. being determined from 'inside'. In this description, the influence of these different approaches for time synchronisation is dealt with. Next, a comprehensive thermal management simulation will be explained.

Time depended calculation of comprehensive systems will be presented for the thermal management of a car, as example. For the simulation of the thermal management (a principle of a thermal management system is shown in Fig. 3) an integrated simulation model has been established (see Regner G., Loibner E.; Krammer J.; Analyses of Transient Drive Cycles using CRUISE-BOOST Co- Simulation Techniques; SAE 2002-01-0627; Puntigam W., Hδrmann T., Schierl K., Wiesler B., Hager J., Thermal Management Simulation by Coupling of Different Software Packages to a Comprehensive System; SAE 2005-01- 2061).

In Fig. 3, a schematic illustration of a thermal system of a car 300 is given, showing an air filter 301, a charge air cooler 302, a condenser 303, a radiator 304, an air cooler 305, an exhaust system 306, an evaporator 307, a driving cycle 308, a driver 309, an ECU 310, a catalyst 311, a turbo charger 312, and a suction system 313.

With an integrated simulation model - Fig. 4 shows a simplified model 400 (illustrating a cooling package 401, an engine 402 and a power train 403) which serves as an example for a comprehensive model in this description - interdependencies between different systems of a vehicle can be represented such as between engine 402 and power train 403. A computable information model of a system is called a partial model. A partial model represents certain aspects of the behaviour of a product (single system, coupled system, up to the virtual vehicle). Consequently the integrated simulation model of the thermal management of a car comprises different partial models, each of which covers a specific simulation aspect of the thermodynamic behaviour (see Samhaber C, Wimmer A., Loibner E., Mahmoud K., Analysis of the Vehicle Performance Using Transient Co-Simulation Techniques; 2002- 5354; Puntigam W., Hόrmann T., Bernasch J., Hager J., Schierl K., Wiesler B. : Thermisches Management im Fahrzeug durch Kopplung unterschiedlicher Simulationsmodelle; Warmemanagement des Kraftfahrzeuges IV, Essen, S.141-S.157; Expert Verlag 2004). Fig. 5 shows the schema 500 of a system-theoretical model of the thermodynamic relevant parts of the underhood of a vehicle (in this description the passenger cabin will not be regarded). Each of the systems and subsystems, e.g. engine 402 or power train 403, is represented in a partial model. Each partial model uses the appropriate information structure related to its behaviour. In order to compute the behaviour different programs may be chosen with different modelling depths, starting from OD simulations for the drive train, over ID models for the cooling system and up to 3D models for the underhood flow as depicted in Fig. 6. Fig. 6 illustrates a diagram 600. Along an abscissa 601, the simulation time is plotted. Along an ordinate 602, the dimension is plotted. Reference numeral 603 indicates the simulation accuracy.

With this strategy calculation time can be reduced dramatically, compared to straightforward fully modelled partial systems. Next, the building of an integrated model will be explained.

For the creation of an integrated model, particularly two strategies are possible:

1. Top-Down Strategy

2. Bottom-Up Strategy. In case 1, a comprehensive physical system will be divided in subsystems. Each subsystem becomes a partial model if the model includes computable information. In case 2, different partial models are available and will be coupled to an integrated model. In both cases the physical parameters, which will be exchanged between the partial models, shall be described. The description of the parameter exchange between the partial models is also called the physical interface of the integrated model

This can be taken from a model 700 shown in Fig. 7 and which considers a consumer power 701, a temperature 702, a heat rpm 703, a torque 704, a load signal 705, and a velocity 706.

In the following, an object model of an integrated model will be explained.

After the description of a physical interface within an integrated model, a way for exchanging the data between the partial models shall be found. Every partial model will be solved by a separate simulation tool. The challenge here is to find a way for coupling these different simulation tools in a time dependent way. As an additional challenge, these different simulation tools can be placed on different computer platforms with different operating systems on it. Therefore, the different simulation tools (partial models) may be regarded as objects with specific features. Each object has specific input and output parameters defined by its physical interface. These parameters are called features of the different partial models.

In Fig. 8 the thermal management system 800 is displayed as an integrated model which is divided in different partial models (objects) with their specific input and output features.

Input parameters are denoted with reference numeral 801, and output parameters are denoted with reference numeral 802.

In an object oriented view of the system the following source code can be written which describes the system in Fig. 8,

OBJECT cooling_package:

IN { velocity, heat, rpm } OUT { temperature, consumer power } OBJECT engine:

IN { load signal, temperature } OUT { heat, rpm, torque } OBJECT power train:

IN { consumer power, driver velocity} OUT { load signal, velocity}

In this object oriented view, the object power train also gets the information of the driver's intended velocity. So it is possible to divide the parameters from the integrated model into inner parameters - which can be in and out parameters - and outer parameters which are the global input data. In addition, global output must be defined. In the present case the temperature is the target value. So the parameter "temperature" is an inner parameter and a global output parameter. In other words, it is possible to describe the inner input and output parameters also as data sinks and data sources (see Fig. 9).

In this context, data sources can also be regarded as suppliers and data sinks as consumers. With these considerations a definition for the special features of the different objects is obtained. In the next step a way has to be found on how to connect the suppliers and consumers over different computer platforms and operating systems. Next, an integration layer will be discussed. A system or interface which connects the data sources and data sinks is called integration layer. This integration layer ought to be implemented in a specific programming language or on an available middleware system such as CORBA. The main task of this layer is to provide a basic communication level where different simulation programs (partial models) can be brought down to one common level (see Fig. 10 illustrating a communication layer 1000).

In this sense, a specific wrapper program is placed in front of each simulation program which translates the simulation program specific API (Application Programming Interface) to the common layer. Therefore three communication commands are provided by the communication layer.

MTS_VAR_DEF { variable, IN or OUT, unit }

MTS_VAR_PUSH { variable, data array, time stamp } MTS_VAR_GET { variable, time stamp }

The whole communication during the simulation is based on these three basic commands which are called by the wrapper program. The wrapper program can also be regarded as an ambassador who calls data of the simulation program via the program specific API and forwards these data via the three basic commands to the communication layer. Additionally, the wrapper reads the data out of the communication layer and negotiates the data to the simulation programs. With the DEF (define) command every simulation object announces its input and output variable names to the communication layer. Using this information the communication layer searches the dependencies between the objects. In other words, the output parameters are published by the objects, the input parameters are announced by the objects, and the communication layer knows the affiliations. This process is performed as a start up process of the comprehensive co-simulation. During the simulation the command PUSH sends actual data information to the communication layer. The GET command reads actual data out of the communication layer. Very important is the time stamp of the data arrays, because this time stamp plays a key rule for the synchronisation process during the time depending simulation.

In the following, the synchronisation process will be explained. Every simulation program which deals with a time depended solution process for differential equations can be divided into three program phases. So, every program can be regarded as an integrator which solves time depending differential equations.

During a start up phase, the program will be started up, some memory resources will be allocated, and some basic data will be initialized. This phase appears only once at the beginning of a simulation.

During a time loop phase, the time value will be increased by one time step and a new loop for the inner iterations will be started to solve the equations from one time level to the next, iteratively (see Fig. 11 showing a control unit 1100, a time dependent control layer 1101 and an integrator 1102). A finishing loop appears only at the end of every simulation. Here memory will be de-allocated, results are written, and the simulation program will be closed.

For the synchronisation process two additional functions may be provided by the communication layer.

MTS_VAR_PU BLISH { IP-address, port number} MTS_VAR_SIM { IP-address, port number}

When a comprehensive simulation consisting of different simulations will be started every single simulation tool must be started separately. Every tool starts with the start up phase. After the start up phase the provided PUBLISH command will be called by every simulation program from the communication layer. This call blocks all programs at the end of the start up phase before the physical simulation start. With this call a defined start signal to all programs is guaranteed. During this call the parameters of every object are published and announced. In this phase the communication layer plays the role of a global registry where input and output parameters are listed. After every object knows its affiliations within the global communication a start signal is handed over to all participants at the same time and the time loop phase starts.

First, every simulation program calculates one time step with its own time step length. After every time step a second blocking command (SIM) will be called. This command checks the actual simulation time proportional to the simulation time of the other participants. The strategy for the calculation of the comprehensive model consists of every simulation tool taking its way to end simulation time with its own time step length. The SIM command checks proportional to the other participants, which program has the lowest simulation time. The program with the lowest simulation time performs the next calculation step. In Fig. 12 (see also Fig. 13) which shows a first program 1200 and a second program 1201, the first integration step from t to t+1 of two different simulation programs with different time step lengths are displayed. After this step program "1" recognizes via the SIM command that it has the lowest simulation time. So the blocking command SIM will be released from the communication layer and the next time step iteration will be performed by program "1" 1200. Program "2" 1201 waits until program "1" 1200 exceeds the simulation time of program "2" 1201.

This synchronisation process ensures an equal simulation time for all participating simulation models. Therefore all integrators which are included within the global simulation model are synchronised. The philosophy behind this process synchronisation lies in achieving the goal of every simulation program reaching the end simulation time with their individual time step sizes. So, every model calculates its own task with its own step sizes, influenced by the inputs of other simulation programs.

System variables can be grouped into three categories:

1.) Input Parameters into the System

2.) Inner Variables of the System

3.) Output Parameters as Output of the System. Input parameters (uθ are parameters which are supplied by other programs or given as input parameters by the user. Inner variables (Xk) of the system can also be regarded as state variables of the system. Output parameters (y_k) are variables which are calculated through the integration process. Within this context, output parameters of the system are always state variables at specific time steps. Input parameters cannot be state variables of the system because input parameters can be regarded as boundary conditions for the integration processes. From one time step to the next, within an integration process the boundary conditions are being held constant. The input parameters change only at specific time steps when new information is provided by another program.

f+l

≠*₊i = ^xk + j /(** > ^uk > «A₊i )* explicit form

/+1

**₊i = ^ + J /(** > ^x*₊i » «t > «*₊i )<# implicit form

Λ ⁼ f(^χ _k+ι ' ^M*₊i ) algebraic equation

An integrator solves the differential equations in the background of the simulation program over the whole simulation time. Therefore input parameters are taken as boundary conditions for the subsystem. The output values y_k are the results of an algebraic equation. Here two possible synchronisation techniques can be distinguished (explicit method - implicit method).

Fig. 14 shows the synchronisation of two different integrators. For a first subsystem 1400 and for a second subsystem 1401, integration 1402 and output 1403 are shown.

In the following, a time synchronisation process will be explained. Using the integration layer presented in this description, explicit and implicit synchronisation is possible. On the left hand side in Fig. 15 an explicit scheme is displayed. There, data exchange is ongoing in the time domain by program "2" handling its output data in step 1 - which is needed by program "2" - to the program "1". Here, Z₂" indicates the state vector of program "2" at the time step n whereas Ziⁿ indicates the state vector of program "1". After the first data exchange program "1" calculates its time step from Zi" to Ziⁿ⁺¹ within his integration process. After the second step program "1" returns its output data to program "2" which also performs its integration process from n to n + 1 in step 4. Important to recognize is the fact, that program "2" has now information about the behaviour of program "1" on the data exchange in step 1 when program "2" starts its integration process. The reaction of program "1" is recognized by program "2" after step 4. There is a delay in getting information back from other programs in terms of the behaviour on changing input data.

A second possibility in data exchange is displayed in Fig. 15, right. There is an implicit process displayed. There, every time step is synchronised until a convergence criterion is reached. For further contributions, only an explicit data exchange for synchronisation will be regarded.

For explicit time synchronisation a synchronisation process with a predictor step is used (Fig. 16).

Within this predictor step the exchanged data will be calculated for the step n+1. The exchanged data from program "1" is used as boundary condition for program "2" and vice versa. In the first step (time n) the boundary conditions are estimated for the time step n + 1 as displayed in Fig. 16. In the second step, the integration process is performed by program "1" and program "2". Two scenarios are possible for the predicator step. The length of the time step of the programs which participate in the coupling process can be different and variable during the simulation. Next, a scenario 1 (parameter interpolation) will be explained.

In Fig. 17 (also showing a zoomed portion 1700) a typical case for interpolating a predictor value is displayed.

In the first step, two programs with different time step length are performing one calculation step. With the strategy which is used within the integration platform - see section "synchronisation process" -, every program uses its time step length until the end of the simulation time. Within step 2 in Fig. 17 the input values for the next calculation (step 3) of program "1" are calculated as average values of program "2". The average value will be calculated from the output values of program "2" with the time information given by program "1" (n and n + 1). These average values are used as input parameters for program "1". Within the integration platform different possibilities for calculating average values are possible.

In Fig. 17 a very simple linear interpolation approach is used. There are also other algorithms available for doing the exchange process over the integration platform. It is important to recognize, that for the calculation of the average value an integral average value is used - in Fig. 17 a linear approach is displayed. It is possible to use also polynomials with higher order. Within the integration platform, a Newton algorithm, and second and third order polynomials can be used for calculating the integral average value between two time steps n and n+1.

a_value = - — — J f(y_k+l , y_k )dt average value

'n+1

Next, a scenario 2 (last parameter information) will be explained. In case 2, shown in Fig. 18, an average value cannot be built for the next calculation step (step 5) of program "1", because there is no parameter information available in program "2" for the next calculation time of program "1". For this reason, the last available information of program "2" (output parameter) is used as an input parameter for program "l".These input parameters are used as boundary conditions for performing step 5 within the integration process of program "1". The last parameter, which is calculated by program "2", is the best available information for an input parameter of program "1", so this parameter is used for the present approach.

In the following, a coupled power train - cooling system simulation application will be explained. A comprehensive simulation model has been built up in such a way that a power train simulation and a cooling system simulation program are coupled to one integrated model. For this example, the simulation tool KULI for the cooling system simulation and the software CRUISE for the power train simulation are used (see Regner G., Loibner E.; Krammer J.; Analyses of Transient Drive Cycles using CRUISE-BOOST Co- Simulation Techniques; SAE 2002-01-0627).

KULI is 1-D thermal-fluid network simulation software. The specification of the air flow network is based on the stream line theory. Determination of the mass flow rate within this branched network can be carried out in a similar way to mass flow in electronic networks where the electrical current corresponds to the flow rate, the voltage to the static pressure loss, and the electrical resistance to the flow resistance. Usually, it is necessary to solve a set of non-linear equations. The equations used by KULI may be based analytically on the conservation equations of mass, momentum and energy.

Fig. 19 shows a KULI model of the air path.

Fig. 20 shows KULI inner circuits.

Next, a simulation of the power train will be explained.

The driving simulation program CRUISE is used for the simulation of the power train with its components such as gear box, engine, and differential. Different driving cycles for reduction or minimization of fuel consumption and improvement or optimization of driving behaviour can be defined in CRUISE: Depending on the driving cycle, on the distance, on the vehicle (gear, driver, tire...), and on the operating point, load signals are generated by CRUISE. The engine is described as a 3D map within the power train simulation tool.

In the following, a comprehensive model will be explained, starting with the cooling system. The main focus of the comprehensive calculation is laid on the interaction between power train and cooling system. Especially the AC (Air Condition) circuit will be regarded in KULI and its influence on the power train by switching it on and off during critical driving conditions.

The water circuit is modelled in a very simple way by only one path, where a radiator and a point mass is placed in the circuit. The AC circuit is modelled in more detail. The circuit consists of one climate condenser and four evaporator modules which are part of the HVAC box. In addition, different resistances caused by tubes are taken into account. For this simulation, a refrigerant compressor is placed in the circuit. Next, a power train will be explained.

In Fig. 21, the power train model is displayed. It comprises a gearbox model, an engine model, and models for the brakes and wheels. With the power train model all torque transmissions of the car are regarded, all torque transmissions of the car are taken care of.

In the following, coupling will be explained. The aim of this coupled run is the simulation of the interaction between the power train and the cooling system. For this purpose, full load acceleration will be investigated. During the acceleration, the AC system is switched on. As a result of the simulation the behaviour of the driving speed and the rpm can be displayed. In KULI, the input enthalpy, output enthalpy, and the mass flow of the refrigerant through the AC compressor are calculated and handed over to CRUISE. In CRUISE a desired curve for the car velocity is presumed. A driver model in CRUISE takes this velocity into account and controls the car model depending on the desired and actual car velocity. The power train simulation hands the actual velocity and the rpm of the engine over to KULI.

Fig. 22 describes the physical interface between KULI and CRUISE. Reference numeral 2200 illustrates output enthalpy, input enthalpy, and mass flow refrigerant. Reference numeral 2201 illustrates engine rpm, car velocity, and bmep.

Next, an implementation will be explained.

The commercial simulation programs within the coupled simulation have to provide interfaces to the outside in order to allow control over their integration process. For the coupled simulation, wrapper programs are provided who are a kind of ambassador between the program interfaces to the outside and the integration layer. These wrapper programs need to be build only once for every program.

A KULI wrapper will be mentioned next. KULI provides a Component Object Model (COM) interface to the outside. This interface is defined by methods which can be called by the wrapper. The wrapper uses the methods which are provided by the integration layer. Via the COM command start-up, time integration, and the finishing phase can be controlled by the following KULI wrapper.

KULI_COM.initialise()

KULI_COM.ScanCOMInterface{in and out COM parameters are read}

MTS_VAR_DEF{ in and out parameters are published} MTS_VAR_PUBLISH{ blocking command }

While KULI_COM_NextTimeStep

MTS_VAR_GET{ new parameters, time} KULI_COM.set_values( parameters write to KULI) KULI COM Innerlteration KULI_COM.get_values( parameters read from KULI) MTS_VAR_PUSH{ new parameters, time}

MTS_VAR_SIM{ new parameters, time} Wend

A CRUISE wrapper will be mentioned next.

CRUISE provides a Dynamic Linked Library (DLL) interface to the outside. The DLL also provides defined methods to the outside. With the help of these methods the CRUISE integration process can be controlled by the outside.

CRUISE_DLL.initialise()

CRUISE_DLL ScanCOMInterface{in and out parameters are read}

MTS_VAR_DEF{ in and out parameters are published} MTS_VAR_PU BLISH { blocking command }

For CRUISE-DLL _TimeStep MTS_VAR_GET{ new parameters, time}

CRUISE_DLL.set_values( parameters write to KULI)

CRUISE_DLL _lnnerlteration

CRUISE_DLL.get_values( parameters read from KULI) MTS_VAR_PUSH{ new parameters, time}

MTS_VAR_SIM{ new parameters, time} EndFor The input parameters from KULI are used for the calculation of the needed compressor power. Power is converted into torque information and taken into account as consumer of the engine.

In the following, simulation results of the coupled simulation will be explained.

A full acceleration case will be discussed as an exemplary result of the coupled simulation task. After 20 sec during the acceleration the AC system will be switched on by the driver. In the following pictures, the reaction on the power train will be observed. In Fig. 23, the reaction of the car velocity is displayed.

Fig. 23 illustrates a diagram 2300. Along an abscissa 2301, the time is plotted. Along an ordinate 2302, acceleration, velocity and distance are plotted.

A curve shows the velocity of the car over time. After 20 sec a decreasing velocity gradient k in time can be observed. The gradient ki indicates the car velocity without the influence of the AC system. Gradient k₂ indicates the influence of the working AC compressor which needs additional power from the engine, compressor, which needs additional power from the engine. In Fig. 24 the influence on the engine power and engine torque can bee seen. A decreasing gradient in time can also been seen there. Fig. 24 illustrates a diagram 2400. Along an abscissa 2401, the time is plotted. Along an ordinate 2402, engine torque, engine power and engine speed are plotted. The reason for the reaction of the power train can be explained with the activation of the AC circuit.

In Fig. 25 the input and output enthalpy over time is displayed in a diagram 2500. After switching the AC system on the refrigerant compressor is working and an almost constant enthalpy and refrigerant flow can be observed. In Fig. 26 the behaviour of the top tank temperature of the cooling circuit is displayed in a diagram 2600. After 20 sec, an increase of the temperature can be seen. On the one hand, the reason lies in an additional heat release from the condenser in front of the water cooler. On the other hand, the raising temperature can be explained by the additional load of the engine. In other words, the engine tries to produce more torque to provide the desired car velocity with the working AC system.

A comprehensive integration system for coupling different simulation models and programs to a global model is presented. The integration layer which ensures data exchange between models via platform and operating system boundaries takes control over the sub models. The integration layer ensures a time dependent control of all the participating partial models. With use of the just presented approach time dependent simulation of the thermal management of passenger cars is possible. A global simulation model can be built very easily by plugging different partial models together. In the very early phase of the development process rough modelling by coupling only three models is possible. In later stages of the development process a more detailed modelling by coupling of more detailed models is supported. With this approach the coupling of models with varying depth in detail which are zoomed between OD, ID, and 3D to a comprehensive model is demonstrated.

In the following, referring to Fig. 27 to Fig. 57, a transient Co- simulation of thermal management systems by coupling of different submodels will be presented. Particularly, engine warm-up will be taken as an example.

The knowledge of the energy flows in vehicles may be relevant for the design and optimization of the thermal system and its components. In this context, the warm-up phase of the engine is a key aspect. By a fast warm-up of the engine, friction losses may be reduced or minimized. Simultaneously, the consumption and the emissions may be reduced.

Conventionally, the individual systems which are part of the thermal management in the vehicle are mapped by separate models. In order to observe the energy flows collectively and to thereby enable to evaluate the feedback between the systems, a more general concept for mapping the thermal management is necessary.

A method according to an exemplary embodiment is based on a partitioned approach for simulating the system of the entire engine from a thermodynamic point of view. The entire vehicle simulation couples the conventionally separately observed individual systems. For this purpose, the implementation of a co-simulation platform is a successful strategy, as described in the following. It may allow the integration of different models which are generated by different (computer) programs. With regard to the warm-up phase of the combustion engine, particularly when driving in winter, the engine is also an essential heat source for heating the passenger cabin. Thus, an improvement or optimization of the thermal management within the car is relevant, in order to be in accordance with emission regulations, consumption targets and the guarantee of the thermal comfort for the passengers. For an optimization, it is relevant that all thermally relevant partial systems in the car engine, cool and/or heating cycles which are in close interaction to one another, are considered in a correct manner.

In order to map these energy flows using numerical simulations, it may be necessary to employ robust and matched models. Conventionally, the individual systems which are part of the thermal management in the car are mapped by different models. The individual models are generated with different tools, wherein commercially available and separately designed software ("in-house tools") may be implemented. The simulation of the systems may be performed separately, and the constraints or frame conditions are usually defined manually. By this approach, it may happen that the energy flows between the individual partial systems are considered only insufficiently. In order to observe the energy flows in a collective manner and thereby make it possible to consider the feedback between the individual components of the system, a more general approach of the mapping of the thermal management is necessary.

The method which will be explained in the following is based on a partitioned approach for simulating the system entire engine from a thermodynamic point of view. The entire vehicle simulation is performed by the coupling of the individual systems which have been considered separately up to now. In this context, the employment of a co-simulation platform is required which allows an integration of different models. The models can be generated in different programs. In the approach disclosed here, the individual models may each be considered as a black box. The co-simulation platform is, in this approach, independent of the used programs and models. The control of the transient simulation may be realized by the co-simulation platform by controlling the individual subsystems in a time synchronous manner. The transient behaviour of the thermal management may be mapped by the coupling of already existing models. When coupling such systems, the stability of the entire simulation consisting of the individual subsystems has to be considered. The simulation platform therefore offers the opportunity to explicitly or implicitly combine the individual models. In the methods presented here, the individual possibilities of the coupling will be discussed and the stability of the entire system will be discussed.

Next, a thermal entire vehicle model, which may also be denoted as a vehicle thermal management system will be illustrated.

The thermal management of cars includes the thermodynamic investigation of the energy flows and their control within the entire system "vehicle". It includes all essential partial systems which are necessary for the consideration of the energy flows within the thermal management of vehicles. The thermal management can only be described completely when all heat sources within the system and all heat transporting members are taken into account. Fig. 3 shows a model for the entire vehicle from a thermal point of view with all relevant components necessary for the thermal management.

The engine is the main heating source within the entire system shown in Fig. 3. By the combustion and by the engine friction, heat is inserted into the system. The energy of these heating sources is guided by various transmission mechanisms within the thermal system. Starting from the combustion volume, the heat is transported via fluidic cycles (water, oil) and via the member structure of the engine. Via the surface of the engine, a small portion of the energy is emitted to the environment by radiation and convection. Due to the water cycle, heat is lead away from the engine and is lead away to the air via the water cooler and the heat exchanger of the heating.

A portion of the energy emitted in the combustion volume may be conducted as a usable power to the power train and may serve for driving the vehicle and for driving auxiliary aggregates. Further energy components are emitted by the emissions to the environment. The individual energy streams are in permanent interaction to one another during operating the vehicle and may influence each other in a strong manner. The interaction between the individual cycles and systems may depend during a driving cycle of the (transient) operation states of the individual systems.

Since the energy streams in the car are distributed on different systems which are in strong interaction to one another results in the fact that, for an accurate analysis of the thermal system, a collective consideration is necessary. Using entire vehicle simulation calculations, the energy streams can be calculated over various transient cycles and predictions may be made with regard to consumption and emissions. In order to perform such entire vehicle calculations, the system shown in Fig. 3 has to be mapped to a simulation model. Generally, for simulating a comprehensive multidisciplinary model, a monolithic and a partitioned approach may be chosen. The distinction of the approaches is related to the way of the solution method of a solution matrix. The term "solution matrix" may denote a matrix which includes a system of equations which have been defined by modelling the respective physical problem.

Fig. 27 shows a distinction between a partial approach 2700 and a monolithic approach 2701. Degrees of generality 2702 and robustness 2703 are issues which have to be considered in this respect.

In case of a monolithic approach, all equations for the respective physical descriptions are formulated within one matrix and are solved entirely. This may also be denoted as a matrix coupling. The matrix coupling may also be denoted as a rigid coupling. For the numerical solution of the equation system, all equations are solved within one program. For the solution of the individual equations within the matrix, the same solution procedure may be applied. In this context, the specific properties of the equations or matrixes (for instance time characteristics, non-linearity, condition numbers, etc.) are not considered. For large calculation works, monolithic approaches for modelling need a lot of processing resources and a lot of calculation time. In case of a partitioned approach, equations are defined for each of the individually considered partial issues which are considered for the physical description. Each individual equation system can be treated by solution methods which may be specifically adjusted to the respective system. Thus, the use of efficient discretion and solution methods for the individual disciplines are made possible. It is possible to use existing programs, so that development time and costs may be kept small when developing new software.

In the method according to an exemplary embodiment of the invention described herein, a partitioned approach is used for modelling generalized technical systems for establishment of an independent co- simulation environment.

Next, the partitioning of the entire system "entire vehicle" in partial models will be explained.

When partitioning the entire vehicle model, a structured procedure may be carried out, which may have three essential steps:

- Definition of the model requirements

- Partitioning of the entire system into partial models

- Coupling of the individual partial models by a physical interface. In the following, the definition of the model requirements will be explained.

In a first step for simulating complex models, a model boundary and context estimation may be carried out. The purpose of the model and the boundary of the model (global system limit) to the exterior may be defined. This step may be very important, since consequently the global system limits of the entire system and the local system limits of the individual systems may be defined. The following global model properties may be described:

- Definition of the purpose

- Model boundary with regard to expected results - Analysis of the interior properties and correlations

- Time boundary

- Possibilities of recycling the model

Based on these considerations, the suitable simulation tools and the modellation depth may be defined. Next, the partitioning of the entire system in partial models will be explained.

In this phase, the results of the first step may be used. For simulating the entire system, it may be required to subdivide the entire system into partial models. This distribution may be dependent on the used simulation programs, but may also depend on the requirements for the entire system and the desired accuracy. Too simple mapping schemes are prone to failure, and too detailed mapping schemes yield too high calculation times. When subdividing the entire system, the inner propertied which have been documented in step 1 have to be observed in more detail. Due to a cause and effect analysis, the distribution of the entire systems may be carried out. Each of the individual partial systems has to be modelled individually. In this respect, the boundary and context analysis for the respective partial models may be carried out. The description of the strategy may be recursively. The distribution of the entire system and partial systems may be an iterative procedure which, depending on complexity of the original model, may need more or less iterations steps.

The strategy for subdividing the entire system in partial systems may be motivated by different requirements. Possible strategies for subdividing the entire system and partial models can be:

- Short calculation times: The reason for the partitioning of an individual system into partial systems may be the calculation time for the numerical solution of system equations. Goal may be a short calculation time. This goal may be achieved by the distribution of the solution of a model in different processes (parallelization of the numerical solution process) or by distributing of each solution method to one process.

- Different modulation depth: The reason for the subdivision of the entire model may be motivated by different modulation depths. Partial problems, which can be mapped in one dimension, may be grouped. Also three-dimensional sub-problems may be grouped and may be coupled to the entire system.

In the here described example, the subdivision of the entire system of Fig. 3 into partial systems is shown in Fig. 28.

Fig. 28 schematically shows a cooling package 2800, a thermal network 2801, an engine 2802 and a power train 2803. Input parameters

2804 are supplied to each of the partial systems, and output parameters

2805 are generated by each system.

In the following, the determination of the physical interface will be explained. The physical interface describes the link of the physical parameters between the individual partial models. The inputs and the outputs (physical interface) of the partial models are linked to the entire system. For the here investigated entire system, the input/output conditions shown in Fig. 29 to Fig. 32 are defined. In the following, the coupling methodology for the transient coupling of partial models will be explained.

After having subdivided the entire vehicle simulation model in individual partial models and the input and output relations (physical interface) of the partial models have been defined, the co-simulation platform has to connect the individual output parameters at the right time in a suitable form with the input parameters. This is a main task of the co-simulation platform. When exchanging the individual parameters, physical conservation laws/equations have to be fulfilled over the system limits. This may include the definition of constraints. These constraints can be defined by appropriate algorithms, as described below. In the following, an object model will be explained. In order to enable a general abstract description of the individual models, the individual partial models may be denoted as objects which can be characterized by a corresponding object oriented description. Using the object oriented description, the individual partial models may be linked. This abstraction may also form the basis for the software implementation of the individual co-simulation environment.

For the considered system, the objects can be declared in the following manner:

OBJECT Engine

IN {Q_Fue,}

OUT {Pind/ Qpiston/ Qhlead/ Qϋner/ Qport; Qεxhaust)"

OBJECT Power train

OUT {Qpπction, Peff}

OBJECT Thermal Network IN {Qpistoru Qhlead/ Qϋner/ Qport/ QFrictioπ}

OUT {Qo,|, Qwater, QA,Γ}

OBJECT Kϋhlsystem

IN {Qoil/ Qwaterv Qcharge-Air} OUT {QRadiator/ QHeater; Qcharge-Air}

By this object oriented description, the physical parameters of the partial models can be connected in some kind of meta-language, for instance:

Powertrain.P_Ind = Engine. P_ϊnύ

In the following, a communication model will be explained. The communication model of the co-simulation environment is oriented at the solution method of numerical simulation programs. When analyzing the sequence within numerical simulation programs, the following structure can be generally defined :

- Initialization phase

- Time integration phase - Interior iterations

- Finalization phase

Fig. 33 illustrates a time loop 3300.

When variables 3302 are known at a time t, interior iterations (integration) 3301 may be carried out in order to calculate the variables 3303 at the time t + 1C

Fig. 33 shows a sequence of the time integration phase in the inner iterations. First, the time integration phase and the initialization phase are carried out, in which the starting conditions and frame conditions are defined. At the end of the time integration phase, the finalization phase is carried out, in which the memory is released or freed, and the final results are output.

In order to enable the communication on software level between the individual partial models, five basis functions may be defined. These basis functions may serve for data exchange (publication and request of data) and the synchronization and the time control.

- MTS_VAR_DEF {variable, IN/OUT, unit, boundaries, initial}

- MTS_VAR_PUBLISH {ip-address, port}

- MTS_VAR_GET {variable, time stamp} - MTS_VAR_PUSH {variable, data array, time stamp}

- MTS_VAR_SIM {ip-address, port}

The function MTS_VAR_DEF serves for the definition of the interface of the individual partial models. With this function, the physical parameters to be exchanged may be defined. It may be defined whether the value is an "IN" or "OUT" parameter. Also the units, the upper and lower boundaries and the initialization value at the beginning of the simulation may be defined with this function. It is also possible to assign further properties like sensitivities of the parameter or conversion limits of the individual parameters. This function may be carried out by each individual or partial model, thereby defining the physical interface between the partial models.

Using the function MTS_VAR_PUBLISH, all physical parameters to be exchanged may be stored in a registration database. Thus, a unique assignment between the individual models with physical input and output parameters within networks is possible. The dependencies, which may be generated within the registration database, are also available for the individual partial models.

The function MTS_VAR_GET allows the receipt of present data, which have previously been requested of the respective partial model as input parameters. When requesting the function, simulation time and the name of the variable of the respective input parameters have to be defined. The simulation time is identical to the simulation time of the partial model which requests the data. Using the transmitted input parameter, the respective partial model may carry out the next simulation step. At the end of the simulation time step, the calculated output parameters can be sent with the function MTS_VAR_PUSH. These output parameters are sent directly to the partial models, which need these output parameters as input parameters for simulation. The function MTS_VAR_SIM serves for synchronizing the individual partial models during the co-simulation. The function may be carried out during the time integration process and may serve as a trigger function. Thus, also different time step widths of the individual partial models may be synchronized. An example for the sending and the receipt of data is: OBJECT Engine OBJECT Power train

Engine. MTS_VAR_DEF {P,_nd/ OUT, kW, 0, 200, 0} Powertrain. MTS_VAR_DEF {P_ιnd, OUT, kW, 0, 200, 0}

Engine. MTS_VAR_PUSH {P_mt, 98, 13.12} Powertrain. MTS_VAR_GET {P_ιnd, 12.10}

In this context, it does not play an important role that the individual programs distinguish the simulation times of "PUSH" and "GET", since the co-simultaneous platform may carry out also the interpolation of the values.

Next, a layer model will be explained. In order to have a general, independent scheme for a co- simultaneous platform, different abstraction layers may be implemented:

- Application layer: The application layer is the top layer and comprises the simulation programs and physical models

- Wrapper layer: The wrapper layer is some kind of translation layer between the specific interface of the simulation programs and the generally valid interface specification of the co-simulation environment.

- Co-simulation layer: The layer which carries out the time synchronous control of the partial models and the numerical stable control

- Implementation layer: The layer in which the individual basic functions and control mechanisms are employed in a program. It is also the basis for a platform and operation system independent communication.

Fig. 34 illustrates such a layer model.

An application layer 3400 is provided, as well as a service layer 3401. Furthermore, wrappers 3402 are shown. Beyond this, an implantation 3403 and a co-simulation layer 3404 are shown.

Thus, Fig. 34 illustrates the layer model of the independent co- simulation environment. As already mentioned, the wrapper layer is some kind of translation layer of the program specific interface and the independent interface specification.

Reference is made to the above KULI wrapper (see "KULI_COM.initialise() ...)• In this example, also the context between the communication model and the layer model is understandable. This wrapper allows an automatic translation of a COM interface to the independent interface specification of the co-simulation platform. Also for other simulation programs, similar full automatic wrappers have been employed. When defining additional parameters to be exchanged, no program work is necessary, since an automatic translation may be carried out. In the following, synchronization and time management will be explained.

The realization of the synchronization and the time management is based on the communication and layer model described beforehand. For the time coupling of partial models, the following modes may be distinguished:

- Explicit coupling (parallel methods or staggered methods)

- Implicit coupling (parallel methods or staggered methods) In the discussed example, both synchronization variants are possible. Most simulation programs can be considered as a so-called black box during the simulation. This means that only the input and output parameters have to be set or read out, and via these data streams, the behaviour of the physical parameters over time may be observed. For the most simulation programs, there is no access to the state vector during the simulation, which allows for an implicit coupling only in a limited manner. Due to this reason, in the following procedure of this example, only explicitly coupled methods are described in detail. The algorithms are in principle also applicable for implicit methods. The following algorithms can be distinguished:

- Parallel coupling methods - Staggered coupling methods

- Any desired target of the coupling order

In order to allow to distinguish in accordance with the time sequence, the following times may be distinguished :

- Physical time: The time which has been modelled within the simulation (for instance the first 360 seconds of the NEDC).

- Simulation time: The representation of the physical time within the simulation model

- Wall clock time: The wall clock time is the absolute time and/or the absolute point of time, at which a simulation has been started and at which a simulation has been terminated. A protocol of this time can be generated by a computer internal clock.

Fig. 35 shows a parallel coupling approach for the example of two partial models.

A simulation program A 3500 and a simulation program B 3501 are shown schematically. The wall clock time is denoted with the reference numeral 3502. A first region 3503 and a second region 3504 are shown as well.

In the case of Fig. 35, both simulation participants may start the individual calculation steps at the same wall clock time. The synchronization is carried out in an automatic manner. When both programs receive new simulation values as input parameters, the following simulation step may be started. Deadlock simulations can be prevented by specific queries (a deadlock situation may be a situation in which both partial models wait for new input parameters of the respective coupling partner. By specific queries, such a situation can be avoided, so that the simulation is not interrupted before reaching the simulation end time).

Fig. 36 shows a sequential coupling approach on the basis of two partial models. In this case, the order of the calculations is fixed. In the following, a time synchronization for different time steps of the partial models will be explained.

When synchronizing partial models with different calculation time step width, the synchronization of the partial models may be performed by the actual simulation points of time of the program. In the following, this procedure of the synchronization will be explained.

At the beginning of the simulation, each partial model calculates a time iteration with a respective simulation time step.

At the end of the time iteration, each partial model sends the calculation results to the respective coupling partner with the function MTS_VAR_PUSH. After receipt of the data with the function

MTS_VAR_GET from the coupling partner, due to the transmission of the simulation time which is included in each data transmission, the present simulation time of the respective coupling partner is known by each coupling participant. Referring to the above Fig. 12, a first program 1200 knows the actual simulation time of a second program 1201 (and vice versa).

After the first time iteration, the function MTS_VAR_SIM blocks each program having a simulation time with a larger value. In the shown example, the function MTS_VAR_SIM in the wrapper of the second program 1201 blocks the iteration process of the second program 1201. In the wrapper of the first program 1200, the blocking function MTS_VAR_SIM is released and the first program 1201 can continue with the iteration process until the next time step. After each iteration, the simulation times are compared. At the second time iteration step of the first program 1200, input parameters from the known discrete results are interpolated, which have been transmitted by the second program 1201. For this procedure, different interpolation functions may be implemented (see Fig. 17).

The following time iterations of the first program 1200 occur in an analog manner. Interpolation methods can be applied during the time iteration process, as long as the end time of the present time integration of the first program 1200 is smaller than the actual simulation time of the second program 1201. When the end time of the time integration of the first program 1200 is larger than the present simulation time of the second program 1201, this has to be considered by the interpolation scheme between two known nodes (see Fig. 18). In this case, the value of the last known node may be used as constraint for the following simulation time step of the first program 1200. It is also possible to employ extrapolation methods here. These methods may result in instabilities during the co-simulation, since in this case, extending over the last known node, values may be predicted, which are based on the already calculated values. For instance, during switch on procedures and strong non-linearities in the model, such extrapolation methods should be avoided and a conservative method may be preferred. When the present simulation time of the first program 1200 is larger than the simulation time of the second program 1201, the blocking function MTS_VAR_SIM may be released from the second program 1201, and the blocking function may be activated in the first program 1200. Afterwards, the second program 1201 may start with the next time integration.

With the here described method, each of the programs iterates up to the defined simulation and with the own calculation time step width. Next, a co-simulation platform for a transient coupled simulation will be explained. The algorithms and models described above form the basis of the co-simulation platform. In order to allow a protocol of the data exchange to be handled via the interface during the co-simulation, a protocol of the data streams (exchanged physical parameters) may be carried out also during the simulation time. Also after the end of the simulation, the data have to be available and have to be assigned to a coupled simulation model. Such a protocol may be carried out via a graphical user interface, which may generate a protocol of the respective data streams and store them in a database. The results can be analyzed with a suitable software, like Excel. The communication between the individual partial models may be carried out in a direct manner, that is to say there it may be dispensible to have a central server which regulates the data exchange between the simulation participants. Therefore, the simulation expenditure within the co-simulation platform may be kept small (see Fig. 37). Alternatively, a central server may be provided to approve exchanged data, for instance with regard to compliance with physical laws.

In Fig. 37, wrappers 3700 are shown. As indicated with reference numeral 3701, a direct data exchange during the iteration process is possible. In the following, specific partial models for mapping the thermal management will be explained.

As described above, the entire system vehicle (see Fig. 3) may be subdivided into four partial models 2800 to 2803 which will be described in the following in more detail. This partial model may be simulated in different simulation programs. Using these partial models, the thermal management of a vehicle may be investigated in detail. Fig. 38 shows a model of a power train 2803. For a simulation of the power train, the simulation program AVL CRUISE may be employed. With this simulation program, the power train and the longitudinal dynamic of the vehicle may be calculated. Within this model, a friction characteristics may be taken into account, with which the effective power may be calculated from the indexed power (of the partial model of the engine). In order to calculate the present temperature dependent friction power, the actual oil temperature may be used as an input parameter for CRUISE, which may be provided from the cooling system simulation program. Furthermore, in CRUISE, all mechanically relevant parameters like vehicle mass, gear box transmission and losses within the transmissions may be taken into account. Within CRUISE, a driver model may be integrated which, based on the given velocity profile, defines the required load signal for the engine. The load signal determined by CRUISE and the actual revolution speed of the engine flange may be transmitted to the program for engine process calculation.

In the second partial model, the engine 2802 is modelled, as shown in Fig. 39.

Using BOOST, a charge modification process may be calculated. The present revolution speed and the load signal may be transmitted from the power train simulation model to BOOST. From the load signal, which equals to the wish of the driver, the required amount of fuel to be injected may be calculated and may be used as an input parameter for the charge modification process calculation. The model includes the sucking system, the emission system and all relevant charge modification influencing members. BOOST may calculate the induced engine moment, which may be transmitted to the power train. During the calculation, also the wall heating streams, which may be caused by the combustion, may be calculated. Furthermore, all wall temperatures may be defined in BOOST, which are calculated from the partial model "thermal network". Therefore, realistic, transient/instationary wall heating streams may be determined. During the simulation of BOOST, the output parameters may be calculated accurately for a cycle (per degree crank angle). Since this resolution for the entire system is too small, the individual parameters may be averaged over cycles and per time (depending on the defined time step in seconds) as output parameters.

Next, referring to Fig. 40, a model for the thermal network 2801 will be explained.

The thermal network has been defined in Matlab/Simulink. The model has been constructed from three basic elements:

- Mass element (capacitive storage)

- Conductive connection elements (between capacitive storages) - Convective connection elements (between capacitive storages and fluid)

Depending on the desired accuracy (degree of detail), the model can be performed with a very rough resolution or with a very fine resolution. For the described investigation, a rough modelling may be selected and the main elements (members) of the engine may be modelled as one mass (cylinder head, cylinder block, piston, liner, cranks, etc.). The individual masses can be linked to one another in accordance with a functional relation. Using the thermal network - starting with wall heating streams (from the engine model) and the present fluid temperatures (from the cooling system model) - the distribution of the heat and the cool medium, in the oil and in the structure are calculated. It is also possible to determine the heating stream to be emitted to the environment by a simplified approach. The calculated heating streams in cooling water and in oil can be transmitted to the cooling system simulation program, in order to calculate the fluid temperatures as a response to the thermal network. The oil temperature may also be transmitted to CRUISE, in order to determine the friction power.

The cool system of the vehicle, consisting of the water and oil cycle and the air cycle, can be mapped with KULI. Apart from the inner cycles, also the air path may be mapped in KULI. For this purpose, also the influence of the charge air cooler may be considered, which inserts heat into the air path and thereby influences the cooling system indirectly. KULI obtains, as input parameters, the emitted heat values in cool water and in oil. In KULI, the present fluid temperatures are determined and are supplied to the thermal network. During the simulation, also the emitted heat values of the heat exchange of the heating, the water cooler and the charge air cooler may be considered. In the simulation model, the vehicle cabin has not been considered, but may be considered if desired. For calculating the air volume stream, a measured blower characteristics and the measured blower operation points may be considered.

A model for the cooling package 2800 is shown in Fig. 41.

The interaction between the oil and the water cycle may be considered by an oil water heat exchanger. The thermal phlegm between the media (cool water and oil) may be considered by point masses.

In the following, transient simulations of the engine warm-up behaviour will be explained.

The warm-up behaviour of the engine has been calculated for a calculation cycle with which a test vehicle can be driven on a test stand (for instance having rolls). The driving cycle has been defined in the simulation program CRUISE.

Fig. 42 shows a diagram in which an abscissa 4200 indicates the time in seconds, wherein a first ordinate 4201 indicates a temperature and a second ordinate 4202 indicates a velocity. A curve 4203 indicates an engine measurement, a curve 4204 indicates a wheel measurement, a curve 4205 indicates a first co-simulation, a curve 4206 indicates a second co-simulation and a curve 4207 indicates a velocity.

In the diagram shown in Fig. 43, a curve 4300 indicates an oil measurement, a curve 4301 indicates a co-simulation, and a curve 4302 indicates a velocity.

The diagram of Fig. 44 indicates an indicated engine power, and shows a comparison of a measurement and a calculation. A curve 4401 indicates a measurement, and a curve 4402 indicates a co-simulation. Along an ordinate 4400 of Fig. 44, the indicated engine power is shown.

Fig. 45 shows a comparison of a measurement and a calculation of the revolution speed of the engine, which is plotted along an ordinate 4500. A curve 4501 indicates a measurement, and a curve 4502 indicates a co-simulation.

Fig. 46 shows a diagram in which the power balance of the coupled entire vehicle simulation is shown.

The power balance of Fig. 46 shows the global energy streams which are exchanged via the limits/boundaries of the system. On the other hand, Fig. 46 shows the internal correlations of the energy streams. The entire power balance has to be balanced, equalized or matched during the entire co-simulation, at each point of time. The global power balance can be defined in the following manner:

Q_Fuel ⁼ Peff + Qεxhaust + Q_Radiator + Q_Heater + QAIΓ

The internal power balance is the exchange of the energies/powers within the coupled system limits. The internal power balance has to be fulfilled at each point of the co-simulation. The internal power balance can be defined in the following manner:

Q out _ r\ in

Friction — ^Friction

P out _ n ⁱⁿ ind — nnd The internal power balance can also be considered as some kind of constraint. Emitted energy contributions coming from partial models have to be received by other partial models. If this constraint is not fulfilled, the local energy balance is not consistent, and energies are lost. For the compliance with the internal constraints, the coupling algorithm plays an important role, since this may determine the quality of the coupling.

Apart from the global power balance (or global energy balance) and the internal power balance (or internal energy balance), also the local power balances (or the local energy balances) of the partial models have to be fulfilled. This is the basis for the generation of a coupled entire model. For the individual partial models, the following local power balances may be defined :

Engine process calculation: QFuel = Pind + Qpiston + Qhlead + Qϋner + Qport + QExhaust

Power train:

Pind = QFπction + Peff

Thermal network:

Qpiston + Q_Head + Qljner + Qport + QFπction ⁼ Qoil + Qwater + QAIΓ + Kapstructure

Cooling system : Qoil + Qwater + Qcharge-Air = QRadiator + QlHeater + Qcharge-Air + Kapstructure

In Fig. 47 and 48, two examples for the power balances (Fig. 47 related to BOOST and Fig. 48 related to Simulink) are shown.

These have been determined by a summation over the first 300 seconds of an exemplary driving cycle. When considering the local power balances, these are equilibrated. Using the co-simulation platform, the individual energy streams during the co-simulation may be controlled at each point of time. By a detailed sectioning of the engine into individual mass contributions, the energy streams may also be analyzed in these members, as shown in Fig. 48.

Next, the evaluation of different co-simulations when using different coupling approaches will be explained.

In this context, the influence of different coupling algorithms to the results of the coupled simulation will be investigated. By the different coupling algorithms, sources and sinks in the internal power balance may occur, which may result in an incorrect warm-up behaviour of the members and fluids within the coupled system. A non-compliance of the internal power balance can occur, although the local power balance of the individual models is fulfilled at each point of time during the co- simulation. The local power balance only shows the consistence within the respective partial model.

For example, when starting the warm-up simulation of an engine, an error in the power balance is documented for individual coupling algorithms. In order to compare the obtained values, the cumulated deviation may be illustrated via specific time intervals.

Next, exemplary evaluations for the power train simulation will be explained.

In case of a parallel coupling, the indicated power P_ind may be transmitted as an input parameter in the power train simulation. This power serves subsequently for determining the effective power. When comparing the emitted power P_ind of BOOST and the received power P_ind of CRUISE, there may be a deviation:

Cumulated over the first 300 seconds - deviation 280,6 kJ (approximately 0,93%). Emitted energy of BOOST: 30104752 J Absorbed energy of CRUISE: 30385313 J

Cumulated over the first 500 seconds - deviation 417 kJ (approximately 0,9%)

Emitted energy of BOOST: 47107190 J Absorbed energy of CRUISE: 47524119 J

Cumulated over the first 800 seconds - deviation 602 kJ (approximately 0,85%)

Emitted energy of BOOST: 71422876 J Absorbed energy of CRUISE: 72025871 J

It is believed that the reason for the slight deviation compared to the exchanged energies originates from the parallel coupling method. During the parallel coupling, both partial models are equal simulation participants and can carry out the integration of the time increments simultaneously.

Fig. 50 is a diagram having an abscissa 5000 along which the time is plotted and having an ordinate 5001 along which the power for the internal energy balance is plotted.

Fig. 50 shows the reason for the cumulated deviation in the internal power balance (constraint). In this illustration, the shift of the information flow is shown, yielding deviations in the internal power balance. Depending on the time dependence of the physical parameter, a positive or negative deviation of the equilibrated internal power balance may result.

Such an event may be monitored and, if desired and if the deviations exceed a predetermined threshold value, may be compensated, for instance by defining corresponding (additional) constraints.

The deviations shown in Fig. 50 may strongly depend on the gradient of the physical parameter, on the time step width of the partial model and on the coupling time step width. The relative deviation in percent is less than 1% after 300 seconds simulation time. This result can be obtained by matching the time step in dependence of the gradient. This deviation of the internal power balance is not dependent on the local power balance.

Next, evaluations will be explained using an example of the cooling package simulation.

Assuming a staggered coupling, contrary to a parallel coupling, a defined calculation order may occur, in which the partial models may be integrated. In the example of the partial coupling between the thermal network and the cooling package simulation program, the following parameters are exchanged: The thermal network calculates the heating streams in cooling water and oil which are required as input parameters by the cooling package simulation program. The following staggered coupling order may be defined:

CRUISE - BOOST - Simulink - KULI

In this case, first CRUISE and BOOST are integrated. Afterwards Simulink. Only after having finished the Simulink calculation, all output parameters are sent to KULI. With these values, KULI carries out the next integration step. By taking this measure, the internal power balance (constraint) is fulfilled at each time of the co-simulation.

No deviation of the internal power balance occurs, as shown in Fig. 53.

An abscissa 5300 plots the time, and an ordinate 5301 plots a heat emitted to water by Simulink and received by KULI. Fig. 53 therefore shows the sequence of the exchanged heat by the simulation time. The heat as an output parameter of the thermal network is identical to the received heat in the cooling system simulation program. In this case, the coupling time step width may be increased without errors occurring in the internal power balance. Also in this example, the local power balances are equilibrated.

Next, extensively coupled simulation models will be discussed. When coupling a plurality of partial models, the link of input and output parameters, as in the discussed example of the thermal management, can be even more complex, without a conservation of the internal power balance being apparent. It may happen that the internal power balance is not fulfilled, even when a staggered coupling is present. The reason may be the selection of the calculation order of the staggered coupling. In the considered example, the coupling of four partial models, 4! combinations are possible. When selecting the calculation order of a staggered method, the physical information flow should be considered and should be taken as a basis for the decision of the order. In the discussed application, the transient coupling of partial models of the thermal management in the order of Fig. 54 is appropriate: However, in case of the above selected calculation order, the internal power balance is not entirely fulfilled.

In the case of Fig. 55, reference numeral 5500, the internal power balance is not fulfilled, since, in the corresponding calculation order, first the indicated power would have to be calculated. As indicated with reference numeral 5501, the internal power balance is fulfilled during the co-simulation in these partial models.

When the order in the first two models is interexchanged, the internal energy balance at each point of time during the co-simulation is fulfilled, as indicated in Fig. 56. Fig. 57 again shows the entire model with system limits 5700. A driving profile 5701, a driving lane 5702, an inclination 5703 and a wind velocity 5704 are shown as input parameters, and an acceleration 5705, a consumption 5706 and emissions 5707 are shown as output parameters. It should be noted that the term "comprising" does not exclude other elements or features and the "a" or "an" does not exclude a plurality. Also elements described in association with different embodiments may be combined.

It should also be noted that reference signs in the claims shall not be construed as limiting the scope of the claims.

Claims

C L A I M S

1. A device (100) for performing an analysis of a physical structure, wherein the device (100) comprises a plurality of analysis units (101 to 105) each adapted for analyzing an assigned one of a plurality of virtual segments in which the physical structure is segmented; a synchronisation unit (111) for synchronising the analyses of the plurality of analysis units (101 to 105) under consideration of physical frame conditions for the physical structure.

2. The device (100) according to claim 1, wherein the synchronisation unit (111) is adapted for synchronising the analyses of the plurality of analysis units (101 to 105) under consideration of at least one laws of nature as the physical frame conditions.

3. The device (100) according to claim 1 or 2, wherein the synchronisation unit (111) is adapted for synchronising the analyses of the plurality of analysis units (101 to 105) under consideration of at least one law of conservation as the physical frame conditions.

4. The device (100) according to any one of claims 1 to 3, wherein the synchronisation unit (111) is adapted for synchronising the analyses of the plurality of analysis units (101 to 105) by adjusting a time increment of the analyses in accordance with the physical frame conditions for the physical structure.

5. The device (100) according to any one of claims 1 to 4, wherein the synchronisation unit (111) is adapted for synchronising a data exchange between the plurality of analysis units (101 to 105) to be in accordance with the physical frame conditions for the physical structure.

6. The device (100) according to any one of claims 1 to 5, comprising a segmentation unit (112) for virtually segmenting the physical structure into the plurality of virtual segments.

7. The device (100) according to claim 6, wherein the segmentation unit (112) is adapted for virtually segmenting the physical structure into the plurality of virtual segments so that each of the plurality of virtual segments comprises one or more interconnected virtual elements.

8. The device (100) according to claim 7, wherein the segmentation unit (112) is adapted for virtually segmenting the physical structure into the plurality of virtual segments so that the one or more elements of each of the plurality of virtual segments form one of the group consisting of a zero-dimensional space, a one- dimensional space, a two-dimensional space, and a three-dimensional space.

9. The device (100) according to claim 7, wherein the segmentation unit (112) is adapted for virtually segmenting the physical structure into a first virtual segment forming a zero- dimensional space, a second virtual segment forming a one-dimensional space, and a third virtual segment forming a three-dimensional space.

10. The device (100) according to claim 9, wherein the first virtual segment is indicative of at least one of the group consisting of a thermal behaviour of an engine of a vehicle, a thermal behaviour of a drive section of a vehicle, a thermal behaviour of a fuel guide of a vehicle, and a thermal behaviour of an exhaust system of a vehicle.

11. The device (100) according to claim 9 or 10, wherein the second virtual segment is indicative of at least one of the group consisting of a thermal behaviour of a fluidic line of a vehicle, and a thermal behaviour of a fluidic network of a vehicle.

12. The device (100) according to any one of claims 9 to 11, wherein the third virtual segment is indicative of at least one of the group consisting of a thermal behaviour of a cooling system of a vehicle, and a thermal behaviour of an engine compartment of a vehicle.

13. The device (100) according to any one of claims 1 to 12, wherein the synchronisation unit (111) is adapted for synchronising a timing of the analyses of the plurality of analysis units (101 to 105).

14. The device (100) according to any one of claims 1 to 13, wherein the synchronisation unit (111) is adapted for transient data exchange between the plurality of analysis units (101 to 105).

15. The device (100) according to any one of claims 1 to 14, wherein the synchronisation unit (111) comprises a plurality of synchronisation sub-units each of which being assigned to one of the plurality of analysis units (101 to 105), wherein the plurality of synchronisation sub-units are adapted for cooperating to synchronise the analyses of the plurality of analysis units (101 to 105).

16. The device (100) according to any one of claims 1 to 15, comprising a definition unit (115) for defining at least one virtual interface coupling the plurality of virtual segments in a manner to simulate mechanical properties of the physical structure.

17. The device (100) according to any one of claims 1 to 16, wherein the plurality of analysis units (101 to 105) are adapted for performing the analyses with different levels of computational burden and/or with different level of detail.

18. The device (100) according to any one of claims 1 to 17, adapted for performing a numerical analysis, particularly a computational fluid dynamics analysis, of a physical structure.

19. The device (100) according to any one of claims 1 to 18, wherein each of the plurality of analysis units (101 to 105) is adapted for analyzing the assigned one of the plurality of virtual segments independently from the other analysis units (101 to 105); wherein the synchronisation unit (111) is adapted for centrally synchronising the analyses of the plurality of analysis units (101 to 105).

20. The device (100) according to any one of claims 1 to 19, wherein the synchronisation unit (111) is adapted for synchronising the analyses in a staggered manner.

21. The device (100) according to any one of claims 1 to 20, wherein the synchronisation unit (111) is adapted for synchronising the analyses in a parallel manner.

22. A method of performing an analysis of a physical structure, wherein the method comprises analyzing a plurality of virtual segments, in which the physical structure is segmented, by a plurality of analysis procedures each analysing an assigned one of the plurality of virtual segments; synchronising the analyses of the plurality of analysis procedures under consideration of physical frame conditions for the physical structure.

23. A computer-readable medium, in which a computer program of performing an analysis of a physical structure is stored, which computer program, when being executed by a processor (101 to 105, 111), is adapted to carry out or control a method according to claim 22.

24. A program element of performing an analysis of a physical structure, which program element, when being executed by a processor (101 to 105, 111), is adapted to carry out or control a method according to claim 22.

25. A method of using a device (100) of any one of claims 1 to 21 for performing a computational fluid dynamics analysis of the physical structure.

26. The method of claim 25, comprising performing the computational fluid dynamics analysis of the physical structure to simulate a time-dependent behaviour of the physical structure.

27. The method of claim 26, wherein the time-dependent behaviour of the physical structure is a warm-up procedure.

28. The method of claim 27, wherein the warm-up procedure is related to at least one of the group consisting of an engine compartment under the influence of waste heat of a cooling unit, a fuel cooling unit, an oil cooling unit, and a cooling unit for a guiding unit.

29. The method of any one of claims 25 to 28, comprising performing the computational fluid dynamics analysis of the physical structure to simulate a vehicle as the physical structure.

30. The method of claim 29, wherein the simulation of the vehicle comprise simulation of a warm-up procedure.

31. The method of claim 30, wherein the warm-up procedure is related to at least one of the group consisting of a warm-up characteristic of an engine of the vehicle, a warm-up characteristic of an operating liquid of an engine of the vehicle, an influence of the warm-up characteristic to a fuel consumption of the vehicle, and an influence of the warm-up characteristic to emissions of the vehicle.