AT505326A2 - Internal combustion engine development device for vehicle, has virtual engine test bench together with power brake exhibiting dynamic model with mass inertia model for internal combustion engine, where bench simulates real engine test bench - Google Patents

Abstract

The device has sub models e.g. physical model and data-based model, assigned to subsystems. A virtual engine test bench for simulation of an internal combustion engine (2) is provided with power brakes (5). The virtual engine test bench simulates a real engine test bench (1). The test bench together with the power brake exhibit a dynamic model with a mass inertia model for the internal combustion engine. The dynamic model is integrated in a hybrid engine model such as suction pipe model, combustion model and/or emission model. An independent claim is also included for a method for model-based development of an internal combustion engine.

Description

···· It ···· - 1 - • · · · · · «· · · · ········· 55707

The invention relates to a device for model-based development of an internal combustion engine, subsystems being associated with submodels, and wherein the device has at least one virtual engine test stand for simulating the internal combustion engine and an engine test stand together with a power brake.

To parameterize engine control units, a considerable number of measurements on engine test benches are necessary in an early project phase, the stationary metering. As more and more actuators are installed in modern internal combustion engines, the number of Verstellparameter increases. Associated with this, the combination possibilities and therefore also the calibration effort increase exponentially. The number of measurements required increases to the same extent, necessitating new application tools and modified methods.

In addition, the development time must be shortened in order to remain competitive in the market. In order to fully exploit cost-effective mass production, few engine families are used in different vehicle types, which additionally increases the application effort.

So that engine test benches can be operated fully automated, unmanned and safe, a great deal of technical effort is necessary. A modern engine test bench consists of numerous systems and programs that communicate with each other via different interfaces. Critical measured variables are constantly monitored by the test bed system in order to minimize the risk of engine damage. To effectively protect the engine, intelligent routines are required, as critical operating points sometimes have to be calculated or estimated in advance. In practice, the parameterization of automatic runs turns out to be very difficult because it depends essentially on the experience and the skill of the application engineer. The task is made even more difficult by careless mistakes and the fact that in the rarest cases all eventualities can be considered in advance.

So it is necessary that the automatic test run is observed by the engineer for a long time after the start and usually has to be aborted and modified several times. Since these activities are naturally performed on the test bench, such a procedure is associated with considerable costs and thus undesirable. In addition, the acceptance decreases, - 2 - - 2 - ································································································ ···································································································································································································· The long parameterization also reduces the time saved by automatic runs in the normal case.

WO 2006/007621 A2 describes a method for investigating the behavior of complex systems by forming a model comprising different measured variables as a function of input variables. In this case, after selecting different measuring points and after carrying out measurements for determining measured variables on a real system, a model is created which depicts the dependence of the measured variables on the input variables. The model is calibrated on the basis of the measured values of the real system obtained at the measuring points and subdivided into at least two partial models, with a first partial model representing a first subset of the measured variables. For the first sub-model, at least one first main influence parameter is identified and an optimal value of the first main influence parameter is determined in each measurement point. Then, the first main influence parameter is interpolated for all meaningful constellations of input variables for calibration of the first submodel. Furthermore, a further submodel for mapping a further subset of the measured variables as a function of the input variables and the previously determined first subset of the measured variables and at least one further main influencing parameter for the further submodel is identified. Finally, an optimum value of the second main influence parameter is determined at each measurement point. This makes it possible, even with a small number of real data determined to create meaningful models that have high prognosis quality.

Furthermore, FR 2 788 143 A1 discloses an automatic calibration method for control software in which a controlled internal combustion engine together with the environment is simulated in an execution phase and the results are analyzed by the computer in an analysis phase following this execution phase.

AT 009.467 U2 discloses a device for simulating a development system for a test stand for a test object with a real automation device for operating the test bench and with a simulation device, wherein the test stand and the test object in the simulation device by means of a simulation data generating test model is modeled and the automation device and the simulation device is connected via the real interfaces of the development facility and the automation facility processes generated simulation data. In the development plant there are a number of real development tools and in the simulation device development models generating device data are provided, whereby the device models at least partially simulation data from the test model 3 ···· ·· ···· · ♦ ···· · · · · · . The development tools are connected via real interfaces with the automation device and / or the simulation device, wherein the development tools process development data. To simulate certain test bench hardware, such as a loading machine, a hardware simulator is provided in the simulation device.

Furthermore, from the AT 009.536 U2 a device for simulating a test bench environment is known, wherein the test bed environment hardware is implemented as a virtual PC on a simulation PC, the system time of the virtual PC is stretched by a factor which is a multiple of the time base of the simulation PC, and wherein the real test software is operated on the virtual PC under the slowed down system time.

The object of the invention is to reduce the necessary in advance for test runs of internal combustion engines on engine test rigs application.

According to the invention, this is achieved in that the real-time capable virtual engine test bench for simulating the real engine test bench together with the power brake has at least one dynamic model with a mass inertia model for the internal combustion engine and the power brake. As a result, a test rig structure with a performance brake can be simulated. The internal combustion engine together with an engine test bench is simulated by corresponding models, wherein the operation of the internal combustion engine is simulated on a virtual engine test bench by at least one real-time engine model, an engine control unit model and a dynamic model.

It is preferably provided that the dynamics model is integrated in the engine model.

The engine model can have at least one intake manifold model and a combustion model, wherein, in particular, the engine model can be adapted to a real engine behavior via operating parameters. The engine model can thus be adapted to a new engine via a few design parameters, such as displacement, number of cylinders or the like.

In order to simulate a realistic engine start, the dynamic model can have a starter model.

The engine model has at least one intake manifold model and a combustion model, preferably also an emission model. - 4 - - 4 - ······························································································ ··········································

In order to be able to use conventional test bench software, it is advantageous if at least one measuring device simulation model is provided.

Analogous to a real engine test bench, the engine operating conditions of the virtual engine can be changed automatically, wherein it is particularly advantageous if the device has an interface to an engine dynamometer system.

The invention will be explained in more detail below by means of an embodiment with reference to the figures.

1 shows the structure of a real engine test stand, FIG. 2 shows the structure of a virtual engine test bench, and FIG. 3 shows a motor model of the virtual engine test bench.

In the construction of a real engine test bench 1 shown in FIG. 1, a real internal combustion engine 2 is subjected to a fully automatic test bench routine, wherein the internal combustion engine is operated via a pedal simulator 4 controlled by an engine test bench system 3 in a predefined driving program, and the pedal simulator 4 is operated directly on the vehicle Engine control unit ECU acts. To load the engine, the internal combustion engine 2 is coupled to a power brake 5. To the internal combustion engine 2, an exhaust gas measuring device 6 and for consumption measurement, a consumption measuring device 7 and optionally further measuring systems 8 are further connected to the exhaust gas measurement.

In the embodiment of a real engine test stand 1 shown in FIG. 1, the engine test bench system 3 includes a control program for the internal combustion engine known by the product name EMCON of AVL LIST GMBH. Furthermore, the engine test bench system 3 shown includes a test bench system software known under the product name PUMA OPEN of the AVL LIST GMBH, which serves for test bench control, for the management of the measuring devices and for the storage of the measurement results. Measuring channels of simple temperature and pressure sensors are read in via the analogue-to-digital converter FFEM (Fast Front End Modules) to the EMCON control system. Both the PUMA OPEN test bed system and the EMCON control system require a real-time system to ensure that certain calculations are processed within a predefined maximum time.

Another task of the software PUMA OPEN is the limit value monitoring. Here, individual measuring channels can be provided with warning and alarm limits, at the triggering of which the test bed system carries out defined procedures. When - 5 - - 5 - ···························································································· ···································································································································································· In addition, it is possible that a reaction is triggered only after prolonged exceeding after a predefined time. Typically, the engine speed, the exhaust gas temperature and the blow-by of the engine are monitored, limit values can also be parameterized via maps. So different limits are possible for different operating points.

In order to be able to perform automated measurements on the real engine test bench 1, a parameterization system 9 is necessary in which the desired test runs can be parameterized. During the test run, it must be able to transmit the necessary commands to the test bench system. Such a parameterization system 9 is, for example, the software CAMEO AVL LIST GMBH, but also represents a modular optimization tool for the computer-aided tuning and optimization of engine controls. As the first function of the CAMEO workflow, any characteristic maps, characteristic curves and fixed values from the engine control unit ECU can be loaded and displayed. Subsequently, the user can create automated test runs to optimize this data. In addition to grid surveys, statistical DoE methods (Design of Experiment) are also available. DoE methods can greatly reduce the number of necessary variations with the same informative value. Operating points, the results of which can be well modeled due to neighboring points, are omitted during the measurement.

In addition, CAMEO has a connection to various application systems and thus to the engine control unit ECU. During the measurement from one operating point, any desired engine variable, such as camshaft position, exhaust gas recirculation (EGR) rates, ignition times, etc., can thereby be changed. This makes it possible to measure multi-dimensional test rooms. The connection to an application system 10 is normally made via a standardized ASAP 3 protocol. This can only be used for communication between two systems. In order to be able to measure ECU channels in the PUMA OPEN test bench system and to save them in the database, a so-called ASAP 3 server is provided, which acts as a switch between the various systems PUMA OPEN and CAMEO. The interface used is in each case a TCP / IP connection (TCP / IP = Transmission Control Protocol / Internet Protocol), whereby the protocols are different: while between the application system 10 and the server an ASAP 3 protocol (ASAP = working group for the standardization of Application systems) was used for the attachment of CAMEO - 6 - ······ ···· * ···· «··· ····· ······ ···· · · ······························································································································································································································== Object Model) and thus internal components of the well-known MICROSOFT operating system WINDOWS is based. In a further step of the CAMEO workflow, the tests created can be automated on the engine test bench 1. The operating point setting and the measurement data acquisition are controlled by the automation system. In some cases, a limit value monitoring in CAMEO makes sense, which can be parameterized by the applicator during test run production. For special application tasks, so-called iProcedures (Intelligent Test Run Procedures) are available, in which very specific test procedures and calculations are realized. This allows special ECU functions to be very effectively and with the utmost protection of the device under test.

After an automatic run the test results are stored in CAMEO and in another module they can be evaluated and optimized. Various tools have been implemented to detect outliers which occasionally occur in practice, and so-called repeat points can already be measured during the automatic run, which allow a statement about the quality of the measurement. In the so-called raw data validation, the data can be assessed by the user and sometimes automatically by CAMEO and suspicious outliers can be removed. There are various graphical display options available that facilitate the detection of outliers. For the automatic model formation again statistical methods are implemented in CAMEO, in order to make a statement about the so-called confidence area. This shows how well the formed model corresponds to reality and in which areas the model is only little trustworthy. In general, it can be said that with higher measurement accuracy, the number of measurement points can be reduced without the model quality deteriorating severely. After completion of the test run, the motor setting parameters can be optimized on the basis of the measured data and afterwards verification runs can be run to secure this data.

In order to be able to use the optimizations also in the ECU, CAMEO has its own map calculator with which maps can be recreated or modified. These can then be transferred directly to the engine control unit.

Another component of CAMEO, which also plays an important role in the virtual engine test bench to be described, is the CAMEO engine - 7 - ·························································································· ······························ ·······································

Extension called RT Extension. It is a software package that can be used to compile MATLAB SIMULINK models and then calculate them in real time (MATLAB-SIMULINK is a commercial platform-independent software from Mathworks Inc., USA).

To determine combustion parameters and indicated torque an indexing system is necessary. The pressure curves in the cylinder are measured using special sensors that can record pressure signals with a bandwidth of up to 800 kHz. With a precise crank angle sensor (resolution of 0.5 ° CA), the pressure curve can be calculated via the crank angle position in the measuring and display unit IndiModul (Indimodul is a product of AVL LIST GMBH).

From the cylinder pressure curve, in turn, the combustion focus and the indicated torque can be derived. In addition, knocking events are detected by the indexing and assessed according to their intensity. All results can be displayed in the program IndiCOM of the company AVL LIST GMBH and sent via a TCP / IP interface from this to PUMA. In addition, IndiCOM is connected to CAMEO's real-time RT Extension system via a controller area network (CAN) bus to enable, for example, real-time combustion control.

As already mentioned, the parameterization of automatic runs always causes major problems which later lead to the cancellation of the test run.

The task of the so-called Torquemappings is to find out the exact influences of the individual engine parameters on the torque. For this reason, ignition angle variations are run in the entire operating range, wherein an operating point is set on the test bench and then the ignition angle is varied here. At selected operating points, the mixture composition and, if required, additionally installed adjustment systems of the engine, such as variable camshafts, exhaust gas recirculation, charge movement flaps or the like, are varied. For quick and effective parameterization of the torque structure, CAMEO has a special procedure called iProcedure, which is also able to protect the motor from critical operating conditions.

In practice, it can be stated that the parameterization of an automatic run is only error-free in the rarest of cases. Very often, clerical errors happen or the applicator notices a motor influence during the run, which he was not aware of before. For this reason, an automatic 8 8 ·· ·· »· · · · ···········································································

Normally, the first start is observed for a long time and usually has to be aborted several times in order to change the parameterization.

When using the Torquemapping-Procedure of CAMEO very often finds the most favorable exhaust gas temperature limit in the automatic run. On the one hand, the limit should be as low as possible in order to prevent a limit violation in the test bench system and the associated abort of the automatic run. On the other hand, in the optimization, however, the entire permissible temperature range up to the upper limit value must be exploited in order to be able to exploit a further power and consumption potential. If the exhaust temperature limit is set too low in the automatic run, it may happen that the Torquemapping procedure tries to achieve a sufficient temperature reserve by further enrichment of the mixture. However, since another desired lambda is parameterized in the control unit, the optimizations for this state are often no longer meaningful.

Another difficulty is the setting of setpoints during an automatic run or the adjustment of channels by CAMEO. The applicator has the possibility to perform such actions in different stages of the test run. If an unfavorable time has been parameterized, this can cause unwanted motor reactions or even a test abort.

The problems mentioned can be largely avoided if automatic runs can be tested in advance in a simulation environment in order to be able to eliminate so many errors in the parameterization in advance. As a result, expensive test bench time can be saved and another part of the work transferred to the office.

The structure of such a virtual engine test stand 11 is shown in FIG. It is essential that the simulation environment from the point of view of the automation system corresponds as much as possible to the real test rig structure and the application engineer can be offered the usual working environment. The application engineer should be able to adopt the parameterized tests as unchanged as possible from the simulator.

The automatic runs are parameterized exactly like on the real motor test bench 1 in CAMEO and also traversed via this program. CAMEO is connected to PUMA OPEN via an ACI interface, which is why the automation functions exactly the same as on the real engine test bench 1.

From the point of view of PUMA OPEN, there is no difference in the simulation environment compared to the structure of the real engine test bench 1. About EMCON pedal - 9 - «-» · ······ · Μ ····· ······ ···························································································································································································································· the CAN bus to a motor model 12 are sent, which is integrated in the expansion module RT Extension by CAMEO. Only the interface is different, but from the point of view of PUMA OPEN this is not a problem.

On the CAMEO RT Extension, which is integrated exactly the same as in the real engine test bench 1, the engine model 12 also runs and calculates the engine dynamics in real time. This real-time environment sends values such as speed and shaft torque back to PUMA OPEN via the CAN bus. Since no engine control unit ECU is used in the simulation environment, any necessary ECU functions in the engine model 12 must also be simulated and included in the calculation. For the same reason, the connection of an application system can be omitted in the simulation environment since there is no real ECU.

Since PUMA OPEN always controls the internal combustion engine 2 via brake torque and pedal value at the real engine test stand 1, the engine model 12 at the virtual engine test bench 11 must also be controlled via these two channels. Using a torque balance and the simulated mass inertia of the engine and brake, the model then calculates the current speed, which is sent back to PUMA OPEN as the response variable.

Thus, the required model is not actually a pure engine model, but rather the entire test rig structure including the power brake has to be simulated.

Since no real engine control unit is available in the simulation environment, no parameters can be adjusted directly in the ECU. However, the engine model 12 must still be able to respond to the setpoint specifications and deliver plausible results. For this purpose, an engine control unit model 18 is required, which fulfills these functionalities. Above all, it must be ensured that the parameters have the same format as in the real ECU and cause the same reactions. In particular, one must consider the absolute or relative adjustment of values. Thus, it may be necessary to emulate complete or at least partially simplified ECU functions within the engine model 12.

Another problem arises in the transmission of the specified in CAMEO ECU setpoints to the engine model 12. At the real engine test 1, the parameters are loaded via the application system 10 from the engine control unit ECU and then precisely these channel names in the test run parametrized. In order to simulate the sequence at the real engine test bench 1 on the virtual engine test bench 11 in the simulation environment, a HiL (hardware in -10 - - 10 - ···········

• the loop) setup necessary. In order to find the essential parameterization errors, however, the clearly simpler solution with an engine control unit model 18 is generally sufficient: If the ECU parameters are replaced in the test parameterization and the information is sent directly to the engine model 12, a significantly simpler design can be realized the reactions of the automatic run nevertheless remain the same. The test procedure in the automation system sometimes requires values from measuring devices, which therefore also have to be provided in the simulation environment. Thus, it is necessary to also simulate various meters in the engine model 12, which send their sizes in the correct format to the engine test bench system 3. The values must be calculated by meter simulation models 19, which also necessitates replication of temperatures, pressures and indexing data within the engine model 12. For tasks deviating from torque mapping, the calculation of the exhaust gas composition may also be necessary.

There are basically different ways to build a motor model. In the case of physically based models, an attempt is made to mathematically simulate the physical laws. This has the great advantage that only constructive variables such as dimensions, material constants, etc. are necessary for the parameterization of the model. However, the knowledge of many technical basics such as fluid mechanics, thermodynamics, mechanics, etc. is required to create such a motor model. Provided that the calculations are correct, however, it is ensured that the course of the individual measured variables is physically correctly mapped.

In practice, it is hardly possible to model all influences down to the last detail, as this makes the calculations more and more complex. Very often, differential equations result, whose solutions can only be determined numerically. Since this takes a lot of computing time, the application of the model in real time is often no longer possible. For this reason, simplifications must be made, which ultimately falsify the model result.

As an alternative to the physically based models, data-based models are often used in practice. To create a motor model, no knowledge of the physical background is necessary, but only the influence parameters on certain sizes must be known. The exact behavior is measured on the engine test bench and the results are stored in maps. This has the great advantage that the real engine behavior is mapped, but the parameterization of such a model is very complex, since a sufficient database is required and this is different for each engine.

The found models can either be stored in the form of polynomial functions or as so-called lookup tables. For complicated models an attempt is increasingly being made to integrate so-called neural networks. These are modeled on the structure of the human brain. In neural networks, any number of inputs are provided with different weighting factors and added together. The values of the first intermediate layer thus calculated are again weighted, added and stored in a second intermediate layer. After a definable number of intermediate layers, the model outputs are finally calculated by renewed weighting and addition. The structure of a neural network, ie the number of inputs and outputs, as well as the number of intermediate layers and the values contained therein, can be freely defined by the user. During the so-called network training, the weighting factors are adapted to an existing set of measurement data that contains both all inputs and the desired model outputs. Training is basically a numerical optimization task that minimizes the error between the model outputs and the existing training data set. In practice, however, often encounter difficulties, especially the areas between the training data problems. Unlike polynomial functions, neural networks do not ensure the course of the model from the outset. Thus, in individual areas, it can lead to a so-called "overfitting". come and in others, the network curves due to missing data points from the actual model history away.

Hybrid models use both physical and data-based models, allowing the different benefits of both systems to be exploited. Where it is easily possible to replicate the physical behavior, physically based models are used. To account for additional influences, data-based correction maps are created, which adapt the model to the real measurement results.

In order to test the basic function of the simulation setup and the communication between the individual systems, a separate motor model has been developed, which is adapted to the requirements of the simulation environment.

The actual engine model described below for a homogeneously operated gasoline engine consists of several subregions. In the intake manifold model, the intake manifold pressure and the incoming air mass are determined via the throttle valve angle and engine speed. The combustion model calculates the output depending on the air mass, fuel quantity and ignition timing

Torque and the exhaust gas temperature. Furthermore, an emission model which is not further explained here can also be included.

Sauqrohr Model 13

The suction pipe model 13 simulates the intake manifold pressure pSR via physical relationships, with the following relationship being valid in a simplified mass balance based intake manifold model: VDK 2kRtu 1- k- 1 KPu) (3) with vDK ... flow velocity in the throttle valve (m / s) κ ... isentropic exponent (-)

Psr ... Intake manifold pressure (Pa) pv ... Ambient pressure (Pa) 7 ^ ... Ambient temperature (K) R ... specific gas constant (J / kg K) For the incoming mass flow: W »= VDK-Äeff

Pdk RT "\

Pdk Pu 0) (4) m2U ... incoming mass flow (kg / s)

The outflowing mass flow from the intake manifold pressure pSR is at the same time the air which enters the cylinder of the engine. This quantity is dependent on the intake manifold pressure pSR / engine displacement and the engine speed, as well as the flow conditions in the intake ports and the timing of the valve train. Since the last two influences are physically very difficult to model and this would later require a huge amount of parameterization, a hybrid model approach represents the best solution in this case.

To assess the function, the measurement of a full load curve on the engine test bench is necessary in advance. To do this, the engine is operated with the throttle fully open and the intake air is de-pressurized when the throttle is fully opened Air mass determined at different speeds. From the results, a characteristic is created, which is stored in the intake manifold model 13.

The current air mass for the respective intake manifold pressure pSR is calculated via the so-called intake line. The real engine shows an approximately linear relationship between the intake manifold pressure pSR and the intake air mass, which can be determined very simply via two points. These are the measured air mass at full load and the partial pressure of the inert residual gas PIRG in the cylinder, which represents the intake manifold pressure at which the residual gas remaining in the cylinder prevents the inflow of fresh air. The sucked air mass is at this pressure so 0.

Although the straight lines are slightly bent at some speeds, no correction has been made in the exemplary embodiment within the motor model 12 described here since the error hardly has any effect in the further calculations and is not relevant for use in the simulation environment. A further simplification in the engine model 12 is obtained by the suppression in the intake manifold at full load can be neglected. The partial pressure of the inert residual gas PIRG in the cylinder is not constant in reality, but is assumed in the engine model 12 for each speed with 200 mbar.

The air mass currently flowing out of the intake manifold is thus calculated via the relationship: m ab = m

Air _VL P SR-PIRG 101,3-20 (5) mab ... outgoing mass flow (kg / s) mLuftVL ... Air mass flow under full load (kg / s) P SR ... Intake manifold pressure (kPa) PIRG ... Partial pressure inert residual gas (kPa)

At the end of the function, the air mass is still scaled by the displacement of the engine, in order to be able to map similarly constructed engines with other displacements with the same parameterization.

The third function within the intake manifold model calculates the intake manifold pressure via a mass balance of the incoming and outgoing mass flow. Under the

Assuming ideal gas behavior, the following equation applies to the mass or pressure change in the intake manifold: PSRVSR = 0 »* - ™ ab) RTSR (6) pSR ... Change in intake manifold pressure (Pa / s) VSR ... Intake manifold volume (m3 )

Tgg ... Temperature in the intake manifold (K) For the temperature of the air in the intake manifold, a mean value of 5 ° C above the ambient temperature was assumed in the model. Thus, the intake manifold pressure pSR is calculated via:

- ™) RTSR dt (7)

SR

Combustion model 14

Probably the most important output variable of an engine represents the output power. In the simulation, this is calculated in the combustion model 14, again using a hybrid approach: the burned fuel mass and an efficiency map are used to calculate the proportion of energy that is delivered to the crankshaft. This is called PIH (indicated power in the high-pressure loop) and represents the area in the working loop of a pV diagram (p ... pressure, V ... volume in the working space).

PIH = ιηΚ8ΗυηΡΙΗ (8) PIH ... indicated power in high pressure loop (kW) mKS ... fuel mass flow (kg / s) Ηυ ... lower calorific value (kJ / kg)

Vpih ·· High-pressure loop efficiency (-) - 15 - ·········· · · · · · · · · · · · · · · · · · ······································

The parameterized efficiency takes into account the optimum engine settings and therefore represents the highest possible power yield. For the fuel mass, it must be taken into account that with a rich mixture, the entire amount can not be burned, as there is too little atmospheric oxygen. The fuel mass must therefore be limited: m m

Air max. Max. Maximum fuel mass flow that can be burned (kg / s) air intake air mass flow rate (kg / s) LSt ... stoichiometric air ratio (-)

The factor LSt is fuel dependent and indicates which air mass is needed to completely burn 1 kg of fuel.

After the maximum power has been calculated for the respective operating point, this is multiplied by the so-called ignition angle efficiency. In order to physically simulate this factor for each operating state, without having to parameterize a large number of data, a hybrid model approach was again selected. About the Zündwinkeleinfluss results in a parabolic curve of the output power. By using a suitable, quadratic equation, this basic course is ensured: ηΖΖΡ = -0.5 -ZZPi + ZZPrel +0.5 (10) ηΖΖΡ ... Ignition angle efficiency (-) ZZPrel ... relative ignition time (-)

The relative ignition time required for the equation is calculated from the relationship: 2¾ = - 16 - 2¾ = - 16 - ················································································· ··· ····································································································································································································································································· % p ZZP ... ignition point (° CA) ZZPjo% P ... ignition point at which half the power is delivered (° KW) ZZPnmP ... ignition point for the maximum power output (° KW)

The firing angle for the maximum power output and the spark timing at which exactly half of the indicated power is delivered are stored in two maps. This can be used to influence the shape of the parabola. In order to prevent the ignition angle efficiency from becoming negative, an additional correction characteristic was implemented in the exemplary embodiment, which changes the course of the curve from ZZP5WoP and approaches the value 0.

The influence of the mixture composition on the indicated performance was neglected in the combustion model 14 described here, but a lambda efficiency could be inserted as a correction factor.

In order to calculate the effective power of the engine, the charge cycle and friction losses have to be subtracted. The charge cycle is again calculated as a hybrid model by the charge cycle in the pV diagram is assumed to be a rectangle. Thus, to determine these losses, only the knowledge about the stroke volume of the engine, the Saugrohrunterdruck and the exhaust back pressure is necessary. The latter is parameterised as a characteristic depending on the mass flow flowing through. This approximation works quite well in the modeling of conventional gasoline engines. For the simulation of a variable valve train this simplification can not be used.

The frictional losses of the engine are stored in a characteristic that is normalized by the number of cylinders. This is based on the assumption that the friction changes linearly with the number of cylinders. Thus, after the deduction of the individual losses, the effective power and thus also the effective torque of the motor can be calculated.

To simulate the engine test stand including the power brake, the engine model 12 further includes a parameterization means 15, a dynamics model 16 together with a starter model 17, an engine control unit model 18 and a measurement device simulation model 19:

Parameterization means 15 Via the parameterizing means 15, the user can adapt the motor model 12 to the real motor type. For this purpose, the knowledge of displacement, number of cylinders, intake manifold, throttle valve diameter and inertia of the engine and the power brake is necessary. These are purely constructive parameters that are normally known for each internal combustion engine (and test rig construction). The entire engine model 12 is scaled over it, which gives the user at all times qualitatively correct results. For the detailed adaptation of the engine model 12 to the real internal combustion engine 2 correction maps can be changed within the individual functions. For this purpose, however, a large number of measured values of the real internal combustion engine is necessary.

Furthermore, the user can specify the ambient conditions in the engine model 12 via pressure and temperature. It is also possible to adapt fuel-specific parameters.

Model 16

The dynamics model 16 calculates an angular acceleration over a moment balance and the inertia of the internal combustion engine 2 and the power brake 5. In addition, a starter model 17 is integrated, which emits a torque when the start bit is set as a function of the speed. As a result, the virtual engine can be accelerated to the starting speed as in reality. The characteristic values for the starter are taken from the data sheet of a real starter and must be adapted when parameterizing a larger internal combustion engine. The following physical principle applies to the calculation of the speed change: (1) • · ·· • t ···· • ·· • · • • • • ····· • • • • • • • • • • • • • • Torque (Nm) Θ ... Mass moment of inertia (kg m2.) ) ώ ... angular acceleration (rad / s2)

From this the formula for the engine speed can be derived: - 18 -

(2) ω0 ... initial angular velocity (rad / s)

Engine control module model 18

In engine control unit model 18, all functions of the engine control unit ECU, which are also necessary for the simulation environment, are simulated. As in the real engine control unit ECU, the measured values of the intake air mass, the speed and the pedal value are required as model inputs. From this, the engine control unit model 18 calculates a relative cylinder charge, a throttle valve angle and a desired lambda value, which is stored in a characteristic map. For application purposes, it is possible to change the lambda value. In another map in the engine control unit model 18, the optimum ignition timing is determined, which can be adjusted for application purposes. In addition, the necessary amount of fuel is calculated, which is necessary in the current air mass to reach the predetermined lambda value.

Messaerätemodell 19

In particular, for internal calculations of the Torquemapping Procedure the parameterization software CAMEO measurements of the exhaust gas temperature and knock probabilities are required. These must also be calculated in the simulation environment of the engine model 12 and transmitted to the test bench system 3.

To model the exhaust gas temperature, a hybrid approach was chosen in the example. The temperature for the optimum engine settings, ie for the maximum power output, are stored in a map. In order to be able to simulate the ignition angle influence on the exhaust gas temperature, the power difference is converted into a temperature difference as a result of the ignition angle efficiency. The evaluation of data of a real internal combustion engine shows that about half of the energy is dissipated via the exhaust gas. The physical relationship can therefore be approximated by the following equation: 19 19 ··

• ·· ·· ♦ · • · · · ·

T3l ... exhaust gas temperature (K) T31maxP ... exhaust gas temperature at maximum power output (K) cp. (12) T3l ... exhaust gas temperature (K) T31maxP ... exhaust gas temperature at maximum power output (K) cp ... specific heat at constant pressure (J / kg K)

In order to model the lambda influence, the calculated exhaust gas temperature is corrected via a characteristic curve. In the end, it is still limited to the ambient temperature down and the rate of change is limited to take into account the real inertia of this system.

To simulate a knock detection, a map with the knock limits is parameterized in the engine model 12. For operating points that are not limited to knocking, very early ignition times are specified, which are never set in practice. In general, a knock probability of 8% is calculated exactly at the knock limit. At even earlier ignition angles, this value increases up to 100% and at a later ignition it drops accordingly.

Claims (15)

- 20 - ····················································································································································································································· 1. A device for model-based development of an internal combustion engine (2), subsystems being assigned to submodels, and wherein the device comprises at least one virtual engine test stand (11) for simulating the internal combustion engine (2) and an engine test stand (1) including power brake (5), characterized in that the real-time capable virtual engine test stand (11) for simulating the real engine dynamometer (1) together with the power brake (5) at least one dynamic model (16) with a mass inertia model Internal combustion engine (2) and power brake (5). 2. Device according to claim 1, characterized in that the virtual engine test stand (11) has at least one preferably hybrid engine model (12), the engine model (12) preferably at least one intake manifold model (13), a combustion model (14) and / or a Emission model includes. 3. Device according to claim 1 or 2, characterized in that the dynamics model (16) in the engine model (12) is integrated. 4. Device according to one of claims 1 to 3, characterized in that virtual engine test stand (11) has at least one starter model (17), wherein preferably the starter model (17) in the dynamics model (16) is integrated. 5. Device according to one of claims 1 to 4, characterized in that the virtual engine test stand (11) for simulating at least one engine control unit (ECU) at least one engine control unit model (18), wherein preferably the engine control unit model (18) in the engine model (12). is integrated. 6. Device according to one of claims 1 to 5, characterized in that the virtual engine test stand (11) has at least one meter simulation model (19), wherein preferably the meter simulation model (19) in the engine model (12) is integrated. 7. Device according to one of claims 1 to 6, characterized in that the virtual engine test stand (11) for operating parameter-based adaptation of the engine model (12) to a real engine behavior at least one parameterizing means (15), wherein preferably the parameterizing means (15) in the Motor model (12) is integrated. 8. Device according to one of claims 1 to 6, characterized in that at least one submodel is a physical model. 9. Device according to one of claims 1 to 8, characterized in that at least one submodel is a data-based model. 10. Device according to one of claims 1 to 9, characterized in that at least one submodel is a hybrid model. 11. Device according to one of claims 1 to 10, characterized in that at least one submodel is modular exchangeable depending on the engine type. 12. Device according to one of claims 1 to 11, characterized in that the device comprises at least one means for preferably automatically changing the engine operating conditions, wherein the means is preferably formed by at least one interface with a motor test rig system (3). 13. A method for model-based development of an internal combustion engine (2), subsystems being assigned to submodels, characterized in that the internal combustion engine (2) together with an engine test bench (1) and power brake (5) is simulated by corresponding submodels, the operation of the internal combustion engine ( 2) on a virtual engine test stand (11) by at least one real-time capable engine model (12), an engine control unit model (18) and a dynamics model (16) is simulated. 14. The method according to claim 10, characterized in that the engine operating conditions of the simulated internal combustion engine by means of at least one engine dynamometer system (3) are preferably changed automatically. 15. The method according to claim 10 or 11, characterized in that the parameterization and / or the software of the engine dynamometer system (3), preferably for an automatic test run on a real engine test bench (1), in a simulation environment of the virtual engine test bench (11) is tested , 2008 09 04 Fu / Sc A-1150 Vienna. Mariahilfer QOrtel 39/17 Tel. (+43 1) 893 89 33-0 Fax; (+43 1) 802 89 333 Dipl.-Ing. Mag. Michael Babeluk