Enginuity FAQ:

A: Enginuity is a Matlab/Simulink-based real-time engine model tool package that supports virtual control system development, system validation and HIL testing of production intent engine controllers. The tool package involves a Simulink based component model library and a set of graphic user interfaces tools that facilitate a swift, automated model calibration process. Enginuity supports port fuel and direct injected spark ignition engine applications, direct injected compression ignition applications, and homogeneous charge compression ignition applications. Enginuity models represent a thoroughly physics-based, zero dimensional modeling approach. The library model blocks are organized within dedicated library modules and are deployed within the Simulink modeling environment in the form of standard Simulink s-function blocks. The set of available s-function blocks entail both fully assembled engine models for various engine applications and module blocks for various physical engine components. A custom Enginuity engine model assembly can thus be built from component modules just like a real engine assembly.

A: You may want to consider Enginuity if you are using Matlab/Simulink as your primary control system design platform and you are contemplating a move toward an entirely virtual engine control system design approach. A critical prerequisite for such an approach is a real-time capable engine model that emulates the relevant static and dynamic engine characteristics with sufficient accuracy across the entire engine operating-envelope. Performance-wise, a fully calibrated Enginuity model fits this description and can be viewed as a particular fleet specimen of the selected target engine application. Thus, within the virtual development paradigm, Enginuity models are used as a substitute for the real engine for all kinds of development tasks. Enginuity models fit seamlessly into the Matlab/Simulink environment and support control strategy development at any level of complexity both for exploratory purposes but also for production intent applications. Possible usages include the swift procurement of linear control models, the initial calibration of controller settings, the validation of algorithm candidates, and many more. Hence, Enginuity is a very powerful tool for embedded engine control system applications that are either subject to extremely challenging lead times or where experimental development efforts must be minimized or both.

A: First and foremost Enginuity models work like any other models that have been built from native Simulink modeling blocks. The model blocks are deployed within custom Simulink system models via the standard Simulink library browser. The library browser modules provide access to either a number of fully preassembled model blocks for various engine application types or to a number of elementary engine component modules that support the swift assembly of custom engine models for any given target engine configuration, i.e., for engines with any number of cylinders and any engine bank and exhaust system configuration. Enginuity also supports arbitrary engine firing orders. In addition to the specific model configuration Enginuity models are customized with respect to a specific target engine application in terms of a predefined set of model parameters. Most of these parameters represent the geometric characteristics of the target engine and material properties. A small portion of the parameters represents regression parameters. These parameters allow for adjusting the torque and gas flow characteristics of the model. This adjustment typically involves a representative set of experimental engine performance data (standard engine mapping data) which is used to formulate a performance error metric. Each step of the entire model calibration process, i.e., the provision and the management of specific model parameters for the engine geometry and for the material properties, the provision and handling of specific engine performance data, and the actual adjustment of the regression parameters as a function of the performance error metric is fully tool supported and largely automated. The customization of an entire model, i.e., the model assembly from library blocks and the model calibration based on experimental data can thus be accomplished within a matter of hours.

A: Enginuity models calculate the engine dynamics on a crank angle basis for each cylinder so that the models inherit the cyclic nature of the real engine. A properly tuned Enginuity model provides high simulation accuracy across the entire engine operating-envelope. Due to the components-based modeling approach (models are built from components just like a real engine) Enginuity affords a high level of model reusability while preserving the flexibility to customize models for particular target applications. Furthermore, due to its real-time capabilities Enginuity not only affords HIL testing but also rapid interactive control system development and testing within the Matlab/Simulink environment.

A: In a nutshell, Enginuity provides models for all engine components which are relevant from a control system development view point. These are all those engine components which affect important engine performance signals such as engine torque, engine speed, and engine mass flow.

A: Dynamic Enginuity model equations are implemented in discrete time notation on the basis of a simple Euler integration method with a fixed sampling rate (integration step size) of 250 μs. This sampling rate corresponds to a crank angle resolution of 0.9 degs at 600 rpm and 9 degs at 6000 rpm. Specific features of Enginuity include cycle-by-cycle engine emulation, emulation of the engine firing order, variable compression ratio, the tracking of 12 individual gas species throughout the engine, the emulation of the port fuel dynamics (for PFI engine applications), the emulation of premixed and diffusion controlled combustion portions (for direct injection engine applications), simple kinetic reaction models (Extended Zeldovich mechanism plus radical formation) and many more.

A: You will need two kinds of data: (1) Model parameter data which describes the physical nature and the geometry of the engine components (inertia of rotating parts, manifold volumes, cylinder bore and stroke, valve lift profiles, etc.) and (2) empirical data which describes the engine performance under stationary conditions (engine mapping data). The latter reflects engine dyno data which OEMs typically collect according to standardized test procedures for each of their engine types. In general, engine mapping data is a collection of steady-state values of a selected number of sensor and actuator signals in a selected number of engine operating points. The selected engine operating points typically span the entire engine operating envelope. The set of required mapping data signals needed to calibrate a particular Enginuity engine model depends on the engine model type, i.e., PFI, CIDI, SIDI, and HCCI (since the required set is a subset of the entire set of model input and output signals). Enginuity comes with a default set of model parameters (and for the case of PFI engines also with some example sets of engine mapping data). The models will work with the default parameters but may not reflect the actual performance characteristics of a specific target engine. You only need mapping data if you are interested in a very accurate engine model. The model accuracy is achieved by optimizing some of the model regression parameters with respect to the available mapping data. The more mapping data you provide the better the model accuracy will be.

A: Regular simulation models are meant for simulation only while HIL models can be used for simulation and for HIL purposes. The code associated with simulation models has been generated from the source model block library (which is not available to customers) using the generic real-time coder while HIL model code has been generated with the embedded real-time coder (refer to the Matlab Real-Time Workshop for more info regarding the code generation tools). The embedded real-time coder generates very efficient code that can be deployed outside Mathworks (Matlab/Simulink) environment. However, the code is generated so that only one instance of a specific model block can be included in a model. For example, you can not generate a model block for a cylinder and then add four instances of this block to an engine model in order to generate a 4-cylinder model. Code generated with the generic real-time coder supports multiple instantiations of the same block within a model. As a consequence, Enginuity HIL models do not offer the same level of feature access as pure simulation models do. For example, in a component-block-based “off-line� Enginuity model, you have access to the outputs of each individual cylinder so that you can monitor the behavior of each cylinder individually, while a component-block-based HIL model only gives you access to the engine block (and not the banks and cylinders it contains). Again, there is no functional difference between the models, so no features have been “cut-off� in order to ensure real-time simulation.

A: Functionally, there is no difference between regular simulation models and HIL models.  The only difference is the level of internal model feature and signal accessibility.

A: CFD (Computational Flow Dynamics) engine models are based on solving the partial differential equations (DEs) of the flow field via a finite-element approach. Enginuity models are based on ordinary DEs. Accordingly, they represent “zero-dimensional� models and do not capture the nature and effects of gas flow dynamics on a spatial basis (pressure wave propagation, etc). However, as opposed to mean-value models, which treat the engine as a continuous pump and capture in-cylinder effects averaged over an engine cycle in terms of look-up tables and/or regression functions, Enginuity models are cylinder-by-cylinder models and capture the effects of heat release, combustion, and instantaneous torque generation on a crank angle basis (for each cylinder individually). Therefore, unlike mean-value model signals, Enginuity model signals such as engine speed, engine torque, manifold pressure, etc. exhibit the oscillating nature one can observe in a real engine.

A: Since Enginuity models reflect a physics-based modeling approach, most of the model parameters have a physical significance.  Contrary to regression-based models (mean-value models are mainly based on regression-based model features) Enginuity has excellent extrapolation capabilities (i.e., Enginuity can predict model performance in data points that are not within the range of regression data used to tune the model behavior).  On the other hand, since Enginuity is based on a zero dimensional modeling approach the models, unlike CFD-based models, execute in real-time and, furthermore, afford interactive engine control system development.

A: Most OEMs have the required data (standard static engine mapping data and spark-torque/lambda-torque sweeps) for each engine readily available. This data is used by OEMs to calibrate numerous features of the engine controller (e.g., volumetric efficiency, MBT spark, etc.). The attached document illustrates the experimental schemes used to procure this data (for a PFI application).

A: A physics-based modeling approach means that the effects of mass and energy storage are models on the basis of first principles rather than on the basis of an empirical modeling approach such as an approach based on linear/non-linear regression models or neural networks.

A: A very good document to gain insight into the physics of combustion engines is the textbook “Internal Combustion Fundamentals� by John B. Heywood (McGraw-Hill, 1988).

A: Misfire detection is a diagnostic feature that has been mandated in the U.S. as part of the federal emission regulations. The regulation mandates that the engine control system must be able to detect any kind of misfires in a given cylinder that may increase the engine emissions. Misfire detection algorithms are typically based on signal-processing schemes (both in frequency and time domain) and analyze the nature of signals which are effected by misfires (engine speed, A/F-ratio, etc.). Since Enginuity captures the effect of misfires on a cylinder individual basis (in accordance with the firing order of the engine), misfire detection algorithms can be designed, tested, and validated with Enginuity models. There is no need to use a real engine during the development phase of misfire detection algorithms.

A: You can disable the bypass valve by setting the model parameter KFLG_ENBL_BYPASS to zero (uncheck the check box in the respective explorer panel). Alternatively, if you are using a components-based engine model, you can remove the bypass model block from the model and rewire the mass flow signal output (only recommended for users who are very familiar with simulink). If the ECU you are investigating includes en electronic throttle control strategy, then it is important that the throttle flow model is tuned correctly (see parameter KTH_AREA_TABLE or KTH_CD_TABLE depending on which throttle model is being used). Otherwise, there is no guarantee that the calibrated throttle control signals are able to provide adequate air and fuel during engine start and during engine idle operation. If there is no electronic throttle control and no idle speed control, i.e., if the throttle is mechanically attached to the gas pedal, then they will have to emulate the driver action during start (press the accelerator pedal down while the ignition key is being applied until the engine runs and then release the gas pedal). Furthermore they will have to ensure that the throttle area for a fully closed throttle is large enough to sustain stable idle operation.

A: Inaccurate Lambda can have two sources: 1) The injector flow rate used in the model does not match the one used in the ECU to calculate the amount of fuel to be injected. 2) One of the signals the ECU needed to calculate the desired amount of fuel is inaccurate (mass air flow, manifold pressure, engine speed, intake air temperature); this could be due to a scaling issue.

A: Enginuity should not be executed at any sampling rate other than 0.00025 s. In order to produce stable solutions of the gas flow equations under all engine operating conditions, Enginuity models must execute at a sampling rate of 250 microseconds. If the computational power of the hardware is insufficient to compute a full Enginuity step within 250 microseconds then this hardware is inappropriate for Enginuity real time model applications (on modern HIL systems with 2GHz-2.4GHz dual core processors the computation of a full Enginuity step for a four cylinder model takes anywhere from 50 to 150 microseconds). Note: If Enginuity is combined with computational expensive IO calculations so that the combined turn-around time for Enginuity plus auxiliary computations exceeds 250 microseconds, a larger sampling rate can be applied if the model portion is encapsulated within an iterative loop that executes at an integer multiple of this larger base rate in such a way that each iteration step is consitent with a 250 microsecond execution rate. For example, if the base rate is set to 1ms then there need to be four iteration steps during one base rate step. All relevant model features (including hardware IO driver blocks) should be implemented within the base rate subsystem (e.g. at a 1ms rate).

A: If a components-based engine model is used (as opposed to an s-function-based engine model) there is literally access to any engine signal anybody may want to analyze (down to the cylinder level). We recommend that components-based models are being used unless the user exactly knows that a s-function-based model is suitable for a particular application. Enginuity is an “open architecture� model. That is, one can make changes to the model configuration to fit any particular needs. For example, some customers may want to implement their own plant model features; or some customers may want to customize the top level model I/O interface and add appropriate port blocks to internal subsystems in order to feed local block signals (e.g., valve lift outputs of cylinder head models, etc.) all the way to the top model level (add signals to the I/O interface).

A: The standard solver used in Enginuity models is a fixed-step forward Euler method. The method requires a sampling rate of 250 microseconds in order to produce stable solutions.

A: The DI demo models are implicitly high pressure common rail models. The rail pressure is a model input which affects the amount of fuel injected into each cylinder. Enginuity does not yet include an actual model of the common rail system. However, since Enginuity is an open architecture model, customers can build common rail injection system models for their specific needs and combine them with Enginuity models. SimuQuest also offer services to develop custom models for any model needs not covered by the standard Enginuity model component set.

A: The overall order of the DE that describes the entire engine model depends on the components that are included. Each individual mass and energy storage device can be described in the form of a first order DE; combining two storage devices leads to a second order DE, etc. The damping depends on the kind of interconnection (parallel, series, with or without feedback). For example, an intake or exhaust manifold and a cylinder are storage devices for mass and energy (in the most basic case these devices require 2 first order DEs each, one for mass and one for energy). Combining an intake manifold in series with N cylinders (parallel) and in series with an exhaust manifold yields an overall system of order 2+2*N+2 (and includes feedback, because the state of each of these devices affects the state of the devices connected to it). Note that this simplistic example does not include additional dynamic effects such as the evaporation of fuel droplets and the transformation of mass during combustion. Each of these effects will increase the order of the overall system. It is important to understand that Enginuity is not a mean value model that can be described with one single DE. Each Enginuity component model is devised according to the physics that govern it. The combination of the model components ultimately determine the overall model behavior.

A: The fact that Enginuity uses only one reference point does not mean that Enginuity is inaccurate in operating points other than the reference point. The idea behind the Enginuity model tuning process is as follows: Use a reference operating point and tune a selected number of tunable model parameters so that an empirical set of spark/lambda sweep (hook) data is matched. Once this step is accomplished use standard engine performance data (static engine mapping data including engine torque, engine air flow, etc.) from across the entire engine operating envelope to tune the remaining set of tunable model parameters so that the model matches the performance data.

A: Enginuity has been sucessfully deployed on dedicated HIL components provided by the following system manufacturers:

• dSPACE
• ADI
• Opal-RT
• National Instruments

A: Enginuity will work on 64-bit systems as long as you have a 32 bit Matlab release installed. Enginuity does not support 64-bit Matlab installations.