- Email: [email protected]
New tools for engine control systems development
A n n u a l Reviews in Control
PERGAMON
Annual Reviews in Control 23 (1999) 109-116
NEW TOOLS F O R ENGINE C O N T R O L SYSTEMS D E V E L O P M E N T
R. K. Stobart l, A. May 1, B. J. Challen l, T. Morel 2
~Arthur D Little Inc, Cambridge MA 2Gamma Technologies Inc
Abstract: Diesel engine control has already become complex, and in order to meet future emissions standards (such as Euro 4) it is likely to be the control system that will provide the needed performance increment. Common rail fuel injection offers yet more degrees of freedom which will need to be exploited as new emissions standards emerge. Whatever the emissions standards, there is a need to reduce risk at the earliest stages in the development of the powertrain. This will involve early and extensive simulation of the powertrain including its control system, sensors and actuators. One emerging approach lies in a combination of a phenomenological model of the engine and a flexible controls environment. To illustrate the principles of developing prototype control systems, we will use the example of the CPower environment, which is a combination of a detailed engine simulation code (GT-Power) and the Simulink simulation environment. Examples of the application of CPower include EGR control, simulation of common rail fuel injection and the simulation of new types of sensor for powertrain control.
Keywords : Engine simulation, engine control, diesel, common rail, EGR, development processes, rapid prototyping.
1. INTRODUCTION The development and support of tools to assist in the development of engine control is an active and growing area. Originating with tools developed within both OEMs and Tier 1 fuel systems suppliers, a number of commercial tools have emerged in recent years. In parallel, some generic tools appropriate to the automotive industry have been adopted and are now integrated into the development processes of major companies.
across the industry the duration development is lengthening.
of
controls
A discussion of the function of development tools also needs to be set in the context of the development process. Models of the development process were first suggested in the earliest days of computer systems development. The motivation behind such models was to provide an underlying structure to the development process to help project management.
The waterfall model of system development was first proposed by Bennington (1956) At this time it was understood that computer systems developments would be impossible without an organised approach. The waterfall model described a process of step-wise refinement which followed the path of specification, design, implementation and testing. 1367-5788/99/$20 © 1999Publishedby ElsevierScienceLtd on behalfof the InternationalFederationof AutomaticControl.All rightsreserved. PII: S 1367-5788(99)00012-7 The underlying need which is propelling change in this field is increased speed in bringing vehicle products to market. The need for progressively more calibration as part of control development means that
110
R. K. Stobart et a l . / A n n u a l Reviews in Control 23 (1999) 109-116
The "V" model described in STARTS (1987) is a development of the waterfall model and puts a stronger emphasis on validation and verification. The V model requires that a full set of documents are complete at each stage of the development process - a situation which is rare in practice. A more adaptive approach is needed for most systems development. It is rare to have a complete system specification for example at the start of a system design and an approach which admits evolution will be more practical. In practice such models are not often followed. This earlier generation of development models does not accommodate "rapid prototyping" which is a prominent and valued feature of engine management development. There needs to be a rational way of including rapid prototyping.
and diagnosis activity in the system.
engine management
What has driven the development of both model based diagnosis and control and rapid prototyping is the need for early reduction of risk in the development process. Any opportunity to take substantial development decisions before hardware is built will result in a saving of both development cost and time. This paper is based on work carried out to build an accurate control development capability using a full phenomenological model of the engine. The result allows the control development process to proceed significantly further in simulation than if conventional modelling techniques were employed. The consequence is an early reduction in development risk. In the following sections we will consider
There are development models which explicitly accommodate a cycle of "progressive refinement". The Spiral Model (Boehm (1988)) accommodates each of the previous models as special cases. In the Spiral Model, the system design is progressively refined through a series of cycles. In each cycle some aspect of the design is developed. Risk assessment and planning are done before entering into the next cycle of refinement. It allows development to proceed where neither requirements nor specification have been well thought out. Rapid prototyping fits well with the spiral model which uses prototype development to answer specific questions about risk before the next phase of system development begins. An engine control system prototype might answer a number of questions, for example: • •
what algorithm is needed to achieve a certain control objective? what sensors will help achieve the control objective?
We will return to these various possible applications of rapid prototyping later in the paper. Underlying tools and process development are changes in both the engine technology under development and the control philosophy or strategy the electronic control unit will implement. There is an underlying shift in philosophy away from map based controls towards more widespread use of models to represent elements of the engine system. Models have the dual advantage of supporting both control
•
• • •
the motivation behind creating a controls prototyping system based on detailed engine simulation the technical aspects of creating the tool the potential utility of CPower in addressing some current and future needs, and future development directions for tools of this type
2. ISSUES DEVELOPMENT
FACING
POWERTRAIN
It is generally accepted that powertrain development is slowed by the control development time. Faster development and calibration are needed to allow faster product development cycles. The interest in rapid prototyping, (see for example Lukich (1997)), is witness to the need to eliminate the delays in system development created by long cycle times. The counter-pressure forcing a lengthening of the development process is the increasing complexity demanded of control systems. Advanced controls, typified by model based systems, require an accurate engine environment for development. The development process needs to include the non-linearities typical of IC engines. Where future control systems are being considered, tools need to answer "what if" questions to guide advanced development. An example concerns the value of cylinder pressure as a feedback parameter.
R. K. Stobart et al. / Annual Reviews in Control 23 (1999) 109-116
111
,-- C o n s t r u c t
Such questions are usually raised before viable hardware is available.
engine
These issues point to the utility of a full non-linear engine model operating in a flexible prototyping environment where controls and data analysis are seamlessly provided. They also point to certain characteristics in the structure of such an environment: •
• •
flexible powertrain representation and operation which allows testing and calibration to proceed just as if there were a test stand available. close integration with the tools for control design and evaluation the ability to represent conceptual sensing and actuation devices.
Overall, advanced modelling can be seen as a means to risk reduction where cost is reduced by delaying the expensive construction and testing of prototypes until significant decisions have been made about the design.
3. MODELING AS
A
MEANS
OF
Figure 1 : the "traditional" course of powertrain and control development
The top line shows the design of powertrain components followed by the construction of prototypes. Development continues on prototypes and meanwhile control design and development is done away from the engine using simplified models. During development the control system is integrated and calibration can continue. An accurate modelling capability changes the process, Figure 2.
I Construct prototype
RISK
REDUCTION The more accurate modelling capabilities of CPower offer a route to risk reduction in engine development. A mean value engine model catches many of the nonlinearities of an engine, but is deliberately simplified to have a manageable execution time for control design purposes. For a review of the capabilities of mean value engine models see Hendriks (1989) and for an example based around the Simulink package see Weeks (1995). Such a model presents only a limited view of the engine and is good in the support of control design and development. However here is a trend in the industry towards a full "paper" representation of much of a vehicle's functionality. The engine is no exception. The traditional process is illustrated in Figure 1.
N Figure 2. A proposal for an improved development process with simulation Now the control design can continue with a representative model of the engine. Integration at this stage is at a low risk because it remains "on paper". Even an initial calibration can be done and which could act as the basis for the first "real world" calibration. Prototype construction need not start until after this initial calibration. Such an approach supports a maxim often adopted in the process industry that a plant should be proven controllable before major investment is made in hardware. The more accurate the engine model, the further into the development cycle the "paper development" can continue. When metal is finally cut most the major decisions concerning the control system will already have been made.
112
R. K. Stobart et al. / A n n u a l Reviews in Control 23 (1999) 109.-116
We have included a brief review of the GT-Power code to illustrate some of the facilities that can now be made available for control systems development. THE CODE 4.
GT-POWER ENGINE SIMULATION
GT-Power is an engine performance simulation suitable for analysis of a wide range of engine issues including advanced engine design concepts. It is based on a one dimensional solution of flow in pipes and volumes complemented by a set of specialised models for physical processes which take place in engines. Such processes include heat transfer, combustion, emissions and engine components include cylinders, valves and turbochargers.
representation of combustion chamber surfaces imported from CAD files. Also, a simple Wiebe model can be used. Turbocharger model represents turbine/compressor balancing, and allows variable geometry VG) turbines and both internal and external wastegates. Multiple turbines and compressors(in series or sequential) can be used. The code is well suited to studies of transient turbocharger response to engine speed and fuelling changes. Structure temperature models allow prediction of temperatures of intake and exhaust pipes, and also of cylinder components (piston, head, valves, cylinder/liner). GT-Power produces steady-state wall temperatures at any speed/load and during transients.
The code solution considers compressible, unsteady, non-linear, one dimensional flow, with finite difference formulation (explicit in time) to provide efficient and numerically stable solutions with exact conservation of mass, species and energy. In addition the code allows quasi-3D flow elements with geometrical description in three dimensions, permitting a realistic description of complex objects (with fast execution speeds) which are well suited for calculation of acoustics.
Individual engine cylinders are fully independent to allow broad flexibility in analysis of thermodynamics and controls,. Any or all of the design parameters can differ from cylinder to cylinder. The crank-train assembly is modelled by a mechanical system model representing all individual moving parts (pistons, connecting rods, crankshaft). The model calculates the instantaneous torque at the flywheel and the instantaneous crankshaft speed (eg during cranking when rpm can vary strongly throughout each cycle).
One of the strong features of the simulation is the treatment of the thermodynamics of gas mixtures. GT-Power tracks in detail mixtures of air, fuel, liquid and vapour, and 11 species of products of combustion. It can fully represent the effects of EGR and the generation of emissions and their transport through the exhaust system. Users can mix their own air from a wide range of species (mixture of N2, O2, H20, CO2, ...) and the effects of air humidity can be included. It allows the use of any fuel : hydrocarbon, methanol, ethanol hydrogen. Real gas calculations are used for accuracy at high cylinder pressures.
GT-Power has been designed to allow transfer of process variables ( pressures, temperatures, RPM, emissions, etc.) to a "wiring harness" for external processing. It can also accept commands back from the harness, controlling engine inputs such as fuelling rate, injection timing, injection pressure, spark timing, throttle angle, orifice diameters, wastegate opening, VGT rack position, etc. As a result GT-Power is well suited to controls analysis using an external controls package such as Matlab/Simulink.
GT-Power will handle any type of piston engine, spark ignited, diesel, 2-stroke or 4-stroke, turbocharged, supercharged or turbocompound. There is a choice of several combustion models For diesel engines there is a model based on the jet plume concept, tracking the evolution of 500 fuel zones, their mixing with air, ignition and then combustion, and calculating heat release and emissions, An alternative is a special three function Wiebe model. For SI engines there is a model based on turbulent flames, featuring detailed three dimensional
5. CREATING THE CPOWER ENVIRONMENT
The CPower environment is a combination of the GT-Power engine modelling code and the Simulink 1 controls simulation package. Simulink provides the
Simulink is a trademark of The Mathworks, Natick, MA
R. K. Stobart et al. /Annual Reviews in Control 23 (1999) 109-116
113
flexible data analysis and dynamic modelling needs to balance the detailed engine modelling of GT-Power. 6. APPLICATIONS OF CPOWER The functions offered by this new tool meet the following criteria : • • •
•
most engine non-linearities can be represented system identification of engine components can be performed with the computer model alone the testing and evaluation of engine strategies which rely on a novel or untested component (a sensor currently in development for example) can be done a rapid evaluation of proposed algorithms strategy elements is available.
GT-Power acts as the nucleus of the CPower system, and offers the common facilities for a wide range of dynamic components. The external control simulation code provides dynamics and control facilities and can if needed extend the dynamics modelling provided by GT-Power. It is this flexible interface which eases the investigation of both controls and novel engine architectures. In the following sub-sections we will briefly review some of the actual and projected applications of CPower. 6.1 Testing sensor proto~pes
The function of the combined tool is illustrated in a screen-dump, Figure 3, which shows a Simulink session. GT-Power can be seen as a Simulink block (a dynamic element) and both input and output data are managed using normal Simulink facilities. The plots show engine speed and torque over a one second period.
GT-Power produces instantaneous "sensor" response, although depending on the internal model formulation, some "reconstruction" of sensor readings may be needed. Real life sensor readings are typically limited by some physical phenomenon such as diffusion or a capacity. This representation is quite straightforward and Figure 4 illustrates the principles using a NOx sensor as an example. Other outputs
Other in[
,
"'" Simple
L
Complex
m Figure 3. Screen Dump of a CPower session showing a simple speed controller. At a detailed level, the interface between GT-Power and Simulink is defined using the normal interface functions. GT-Power is represented as a normal function block. The Simulink block structure is scanned every sample interval. At every such sample, control is transferred to GT-Power through a function call, where the engine model is integrated, before control is transferred back to Simulink. In every respect GT-Power behaves as a regular Simulink dynamic block, with variables passed using the "wiring harness".
Figure 4. Representing sensor dynamics with an NOx sensor as an example.
One key area for sensor and control evaluation is in the application of cylinder pressure in feedback control. For the significance see Powell (1993) The complexity and cost of experimentation is such that a rapid evaluation environment such as CPower will help answer some long-standing questions. The questions are mostly related to cost/performance trade off. For medium speed engines, interferometric
,
114
R. K. Stoburt et al. / Annual Reviews in Control 23 (1999) 109-116
methods have been proposed. See Atkins (1995) for an example concerned with the balancing of individual power contribution from the cylinders of natural gas powered engines. Low cost sensors have been proposed for passenger cars but the detailed understanding of their potential contribution to performance has not been reported. 6.2 Developing controls Jbr fuel injection systems The control of fuel systems poses a variety of challenges. In the short term the maintenance of rail pressure throughout the operating regime of a vehicle is a challenge, while in the long term real time control of rate shaping offers substantial llexibility. A typical arrangement of Simulink-like blocks representing the dynamics of a common rail FIE system is shown in Figure 5: Delivery rate
Delivery rate
Injection pressure
The model, Figure 6 is split between those parts implemented in Simulink and those contained within GT-Power. The interface is through the "wiring harness". In the Simulink part the different components are represented by their dynamics, and steady state behaviour. The link between the pump and the rail is through a pressure regulator which dumps the high pressure fuel should the rail pressure exceed the current required value. The two values passed from the pump to the rail are fuel pressure and flow rate. The rail model is potentially complex because it must accommodate both fuel properties and the behaviour of the rail under high pressure. Geometry must be known to properly simulate pressure wave action. The interfaces between the controls and the engine simulation are well defined. GT-Power requires some simple injection characteristics which can be readily generated by Simulink.
6.3 EGR control development A typical modern EGR system is illustrated in Figure 7.
Figure 5. Overview of the dynamic model of a diesel engine equipped with common rail FIE. In more detail, the model becomes:
Intercooler Supplv
I
EGR valve
q i ~ t ili~ #
Figure 7. An illustration of a High pressure EGR system
Figure 6. The common rail system with a more detailed presentation of the dynamic elements.
Exhaust gas is circulated on the high pressure side of the boost pressure system and is regulated by both an EGR valve and a variable geometry turbocharger.
R. K. Stobart et al. / Annual Reviews in Control 23 (1999) 109-116
This is a complex system with two primary control inputs and two controlled outputs : EGR rate and manifold pressure. The precise interface between engine and control simulation requires careful formulation to get the best from both tools. One approach may be as illustrated in Figure 8 : $imulink
EGR demand
115
of control systems for engines, both diesel and spark ignition. The application of controls related functions allows the scope of the detailed engine simulation code (GT-Power) to be considerably enhanced. The overall effect of this modelling architecture is to make the engine model more accessible to controls system development and to offer controls design tools to powertrain engineers. This is a welcome effect of creating a means of communication.
Load demand
Perhaps the most significant effect of CPower is to reduce risk in the design, development and evaluation of control systems. While this is a general attribute, the particulars include the co-engineering of controls and their calibration with the engine.
Figure 8. The structure of a Simulink/GT-Power model for EGR control This approach considers both EGR and air flow as independent parameters. In practice the air flow would be set by another control algorithm responsible for load control. The two separate loops controlling respectively air flow and air-fuel ratio are supplemented by a model which predicts the behaviour of the EGR system. This model is used to preset the EGR and VGT valve positions in a feedforward sense. Within the control simulation package it is also necessary to model the dynamics Of the valves. Here the simulation might also use the drive voltages or pneumatic pressure available to drive the valves. The engine simulation code will simulate the complex gas dynamics and heat transfer associated with the EGR sub-system. The interface again is quite clean, and leaves the controls specialist able to concentrate on the control design requirements. 7. CONCLUSIONS DEVELOPMENTS.
AND
Future needs are dominated by new engine combustion systems and the "sensing" of new phenomena. Examples include gasoline direct injection, use of knock as a feedback parameters and the use of parameters derived from cylinder pressure. Conceptual new sensors will include burn rate and fast NOx sensors. Armed with this approach, such schemes can be investigated in detail and early decisions made about their viability without excessive engineering expenditure. REFERENCES Atkins, R A, Lee-Chung, E, and Taylor H F (1995). Fiber Optic In-Cylinder Pressure Sensor Developed, Diesel and Gas Turbine Worldwide, April 1995, Vol 27, No 3, ppl6b-16d Bennington, H D (1956). Production of Large Computer Systems, Proceedings ONR, Symposium on Advanced Programming Methods for Digital Computers, June 1956 Boehm, B W (1988). A Spiral Model of Software Development and Enhancement, IEEE Computer, May 1988 Hendricks E (1989). The Analysis of Mean Engine Models, SAE 890563
FURTHER
Lukich, M (1997). Rapid Prototyping of Embedded Systems : 1997 Update, SAE 97EIC-17.
CPower represents a significant step in the development of accessible tools for the development
Powell J D (1993). Engine Control Using Cylinder Pressure : Past, Present and Future, Journal of
116
R. K. Stobart et al. /Annual Reviews in Control 23 (1999) 109-116
Dynamic Systems, Measurement and Control, June 1993, Vol 115, pp343-350 The STARTS Guide to methods and software tools for the construction of large real time systems, NCC Publications, Hobbs Southampton, 1987 Weeks, R and Moskwa, J (1995). Automotive Engine Modelling for Real Time Control Using Matlab/Simulink, SAE 950417
PERGAMON
Annual Reviews in Control 23 (1999) 109-116
NEW TOOLS F O R ENGINE C O N T R O L SYSTEMS D E V E L O P M E N T
R. K. Stobart l, A. May 1, B. J. Challen l, T. Morel 2
~Arthur D Little Inc, Cambridge MA 2Gamma Technologies Inc
Abstract: Diesel engine control has already become complex, and in order to meet future emissions standards (such as Euro 4) it is likely to be the control system that will provide the needed performance increment. Common rail fuel injection offers yet more degrees of freedom which will need to be exploited as new emissions standards emerge. Whatever the emissions standards, there is a need to reduce risk at the earliest stages in the development of the powertrain. This will involve early and extensive simulation of the powertrain including its control system, sensors and actuators. One emerging approach lies in a combination of a phenomenological model of the engine and a flexible controls environment. To illustrate the principles of developing prototype control systems, we will use the example of the CPower environment, which is a combination of a detailed engine simulation code (GT-Power) and the Simulink simulation environment. Examples of the application of CPower include EGR control, simulation of common rail fuel injection and the simulation of new types of sensor for powertrain control.
Keywords : Engine simulation, engine control, diesel, common rail, EGR, development processes, rapid prototyping.
1. INTRODUCTION The development and support of tools to assist in the development of engine control is an active and growing area. Originating with tools developed within both OEMs and Tier 1 fuel systems suppliers, a number of commercial tools have emerged in recent years. In parallel, some generic tools appropriate to the automotive industry have been adopted and are now integrated into the development processes of major companies.
across the industry the duration development is lengthening.
of
controls
A discussion of the function of development tools also needs to be set in the context of the development process. Models of the development process were first suggested in the earliest days of computer systems development. The motivation behind such models was to provide an underlying structure to the development process to help project management.
The waterfall model of system development was first proposed by Bennington (1956) At this time it was understood that computer systems developments would be impossible without an organised approach. The waterfall model described a process of step-wise refinement which followed the path of specification, design, implementation and testing. 1367-5788/99/$20 © 1999Publishedby ElsevierScienceLtd on behalfof the InternationalFederationof AutomaticControl.All rightsreserved. PII: S 1367-5788(99)00012-7 The underlying need which is propelling change in this field is increased speed in bringing vehicle products to market. The need for progressively more calibration as part of control development means that
110
R. K. Stobart et a l . / A n n u a l Reviews in Control 23 (1999) 109-116
The "V" model described in STARTS (1987) is a development of the waterfall model and puts a stronger emphasis on validation and verification. The V model requires that a full set of documents are complete at each stage of the development process - a situation which is rare in practice. A more adaptive approach is needed for most systems development. It is rare to have a complete system specification for example at the start of a system design and an approach which admits evolution will be more practical. In practice such models are not often followed. This earlier generation of development models does not accommodate "rapid prototyping" which is a prominent and valued feature of engine management development. There needs to be a rational way of including rapid prototyping.
and diagnosis activity in the system.
engine management
What has driven the development of both model based diagnosis and control and rapid prototyping is the need for early reduction of risk in the development process. Any opportunity to take substantial development decisions before hardware is built will result in a saving of both development cost and time. This paper is based on work carried out to build an accurate control development capability using a full phenomenological model of the engine. The result allows the control development process to proceed significantly further in simulation than if conventional modelling techniques were employed. The consequence is an early reduction in development risk. In the following sections we will consider
There are development models which explicitly accommodate a cycle of "progressive refinement". The Spiral Model (Boehm (1988)) accommodates each of the previous models as special cases. In the Spiral Model, the system design is progressively refined through a series of cycles. In each cycle some aspect of the design is developed. Risk assessment and planning are done before entering into the next cycle of refinement. It allows development to proceed where neither requirements nor specification have been well thought out. Rapid prototyping fits well with the spiral model which uses prototype development to answer specific questions about risk before the next phase of system development begins. An engine control system prototype might answer a number of questions, for example: • •
what algorithm is needed to achieve a certain control objective? what sensors will help achieve the control objective?
We will return to these various possible applications of rapid prototyping later in the paper. Underlying tools and process development are changes in both the engine technology under development and the control philosophy or strategy the electronic control unit will implement. There is an underlying shift in philosophy away from map based controls towards more widespread use of models to represent elements of the engine system. Models have the dual advantage of supporting both control
•
• • •
the motivation behind creating a controls prototyping system based on detailed engine simulation the technical aspects of creating the tool the potential utility of CPower in addressing some current and future needs, and future development directions for tools of this type
2. ISSUES DEVELOPMENT
FACING
POWERTRAIN
It is generally accepted that powertrain development is slowed by the control development time. Faster development and calibration are needed to allow faster product development cycles. The interest in rapid prototyping, (see for example Lukich (1997)), is witness to the need to eliminate the delays in system development created by long cycle times. The counter-pressure forcing a lengthening of the development process is the increasing complexity demanded of control systems. Advanced controls, typified by model based systems, require an accurate engine environment for development. The development process needs to include the non-linearities typical of IC engines. Where future control systems are being considered, tools need to answer "what if" questions to guide advanced development. An example concerns the value of cylinder pressure as a feedback parameter.
R. K. Stobart et al. / Annual Reviews in Control 23 (1999) 109-116
111
,-- C o n s t r u c t
Such questions are usually raised before viable hardware is available.
engine
These issues point to the utility of a full non-linear engine model operating in a flexible prototyping environment where controls and data analysis are seamlessly provided. They also point to certain characteristics in the structure of such an environment: •
• •
flexible powertrain representation and operation which allows testing and calibration to proceed just as if there were a test stand available. close integration with the tools for control design and evaluation the ability to represent conceptual sensing and actuation devices.
Overall, advanced modelling can be seen as a means to risk reduction where cost is reduced by delaying the expensive construction and testing of prototypes until significant decisions have been made about the design.
3. MODELING AS
A
MEANS
OF
Figure 1 : the "traditional" course of powertrain and control development
The top line shows the design of powertrain components followed by the construction of prototypes. Development continues on prototypes and meanwhile control design and development is done away from the engine using simplified models. During development the control system is integrated and calibration can continue. An accurate modelling capability changes the process, Figure 2.
I Construct prototype
RISK
REDUCTION The more accurate modelling capabilities of CPower offer a route to risk reduction in engine development. A mean value engine model catches many of the nonlinearities of an engine, but is deliberately simplified to have a manageable execution time for control design purposes. For a review of the capabilities of mean value engine models see Hendriks (1989) and for an example based around the Simulink package see Weeks (1995). Such a model presents only a limited view of the engine and is good in the support of control design and development. However here is a trend in the industry towards a full "paper" representation of much of a vehicle's functionality. The engine is no exception. The traditional process is illustrated in Figure 1.
N Figure 2. A proposal for an improved development process with simulation Now the control design can continue with a representative model of the engine. Integration at this stage is at a low risk because it remains "on paper". Even an initial calibration can be done and which could act as the basis for the first "real world" calibration. Prototype construction need not start until after this initial calibration. Such an approach supports a maxim often adopted in the process industry that a plant should be proven controllable before major investment is made in hardware. The more accurate the engine model, the further into the development cycle the "paper development" can continue. When metal is finally cut most the major decisions concerning the control system will already have been made.
112
R. K. Stobart et al. / A n n u a l Reviews in Control 23 (1999) 109.-116
We have included a brief review of the GT-Power code to illustrate some of the facilities that can now be made available for control systems development. THE CODE 4.
GT-POWER ENGINE SIMULATION
GT-Power is an engine performance simulation suitable for analysis of a wide range of engine issues including advanced engine design concepts. It is based on a one dimensional solution of flow in pipes and volumes complemented by a set of specialised models for physical processes which take place in engines. Such processes include heat transfer, combustion, emissions and engine components include cylinders, valves and turbochargers.
representation of combustion chamber surfaces imported from CAD files. Also, a simple Wiebe model can be used. Turbocharger model represents turbine/compressor balancing, and allows variable geometry VG) turbines and both internal and external wastegates. Multiple turbines and compressors(in series or sequential) can be used. The code is well suited to studies of transient turbocharger response to engine speed and fuelling changes. Structure temperature models allow prediction of temperatures of intake and exhaust pipes, and also of cylinder components (piston, head, valves, cylinder/liner). GT-Power produces steady-state wall temperatures at any speed/load and during transients.
The code solution considers compressible, unsteady, non-linear, one dimensional flow, with finite difference formulation (explicit in time) to provide efficient and numerically stable solutions with exact conservation of mass, species and energy. In addition the code allows quasi-3D flow elements with geometrical description in three dimensions, permitting a realistic description of complex objects (with fast execution speeds) which are well suited for calculation of acoustics.
Individual engine cylinders are fully independent to allow broad flexibility in analysis of thermodynamics and controls,. Any or all of the design parameters can differ from cylinder to cylinder. The crank-train assembly is modelled by a mechanical system model representing all individual moving parts (pistons, connecting rods, crankshaft). The model calculates the instantaneous torque at the flywheel and the instantaneous crankshaft speed (eg during cranking when rpm can vary strongly throughout each cycle).
One of the strong features of the simulation is the treatment of the thermodynamics of gas mixtures. GT-Power tracks in detail mixtures of air, fuel, liquid and vapour, and 11 species of products of combustion. It can fully represent the effects of EGR and the generation of emissions and their transport through the exhaust system. Users can mix their own air from a wide range of species (mixture of N2, O2, H20, CO2, ...) and the effects of air humidity can be included. It allows the use of any fuel : hydrocarbon, methanol, ethanol hydrogen. Real gas calculations are used for accuracy at high cylinder pressures.
GT-Power has been designed to allow transfer of process variables ( pressures, temperatures, RPM, emissions, etc.) to a "wiring harness" for external processing. It can also accept commands back from the harness, controlling engine inputs such as fuelling rate, injection timing, injection pressure, spark timing, throttle angle, orifice diameters, wastegate opening, VGT rack position, etc. As a result GT-Power is well suited to controls analysis using an external controls package such as Matlab/Simulink.
GT-Power will handle any type of piston engine, spark ignited, diesel, 2-stroke or 4-stroke, turbocharged, supercharged or turbocompound. There is a choice of several combustion models For diesel engines there is a model based on the jet plume concept, tracking the evolution of 500 fuel zones, their mixing with air, ignition and then combustion, and calculating heat release and emissions, An alternative is a special three function Wiebe model. For SI engines there is a model based on turbulent flames, featuring detailed three dimensional
5. CREATING THE CPOWER ENVIRONMENT
The CPower environment is a combination of the GT-Power engine modelling code and the Simulink 1 controls simulation package. Simulink provides the
Simulink is a trademark of The Mathworks, Natick, MA
R. K. Stobart et al. /Annual Reviews in Control 23 (1999) 109-116
113
flexible data analysis and dynamic modelling needs to balance the detailed engine modelling of GT-Power. 6. APPLICATIONS OF CPOWER The functions offered by this new tool meet the following criteria : • • •
•
most engine non-linearities can be represented system identification of engine components can be performed with the computer model alone the testing and evaluation of engine strategies which rely on a novel or untested component (a sensor currently in development for example) can be done a rapid evaluation of proposed algorithms strategy elements is available.
GT-Power acts as the nucleus of the CPower system, and offers the common facilities for a wide range of dynamic components. The external control simulation code provides dynamics and control facilities and can if needed extend the dynamics modelling provided by GT-Power. It is this flexible interface which eases the investigation of both controls and novel engine architectures. In the following sub-sections we will briefly review some of the actual and projected applications of CPower. 6.1 Testing sensor proto~pes
The function of the combined tool is illustrated in a screen-dump, Figure 3, which shows a Simulink session. GT-Power can be seen as a Simulink block (a dynamic element) and both input and output data are managed using normal Simulink facilities. The plots show engine speed and torque over a one second period.
GT-Power produces instantaneous "sensor" response, although depending on the internal model formulation, some "reconstruction" of sensor readings may be needed. Real life sensor readings are typically limited by some physical phenomenon such as diffusion or a capacity. This representation is quite straightforward and Figure 4 illustrates the principles using a NOx sensor as an example. Other outputs
Other in[
,
"'" Simple
L
Complex
m Figure 3. Screen Dump of a CPower session showing a simple speed controller. At a detailed level, the interface between GT-Power and Simulink is defined using the normal interface functions. GT-Power is represented as a normal function block. The Simulink block structure is scanned every sample interval. At every such sample, control is transferred to GT-Power through a function call, where the engine model is integrated, before control is transferred back to Simulink. In every respect GT-Power behaves as a regular Simulink dynamic block, with variables passed using the "wiring harness".
Figure 4. Representing sensor dynamics with an NOx sensor as an example.
One key area for sensor and control evaluation is in the application of cylinder pressure in feedback control. For the significance see Powell (1993) The complexity and cost of experimentation is such that a rapid evaluation environment such as CPower will help answer some long-standing questions. The questions are mostly related to cost/performance trade off. For medium speed engines, interferometric
,
114
R. K. Stoburt et al. / Annual Reviews in Control 23 (1999) 109-116
methods have been proposed. See Atkins (1995) for an example concerned with the balancing of individual power contribution from the cylinders of natural gas powered engines. Low cost sensors have been proposed for passenger cars but the detailed understanding of their potential contribution to performance has not been reported. 6.2 Developing controls Jbr fuel injection systems The control of fuel systems poses a variety of challenges. In the short term the maintenance of rail pressure throughout the operating regime of a vehicle is a challenge, while in the long term real time control of rate shaping offers substantial llexibility. A typical arrangement of Simulink-like blocks representing the dynamics of a common rail FIE system is shown in Figure 5: Delivery rate
Delivery rate
Injection pressure
The model, Figure 6 is split between those parts implemented in Simulink and those contained within GT-Power. The interface is through the "wiring harness". In the Simulink part the different components are represented by their dynamics, and steady state behaviour. The link between the pump and the rail is through a pressure regulator which dumps the high pressure fuel should the rail pressure exceed the current required value. The two values passed from the pump to the rail are fuel pressure and flow rate. The rail model is potentially complex because it must accommodate both fuel properties and the behaviour of the rail under high pressure. Geometry must be known to properly simulate pressure wave action. The interfaces between the controls and the engine simulation are well defined. GT-Power requires some simple injection characteristics which can be readily generated by Simulink.
6.3 EGR control development A typical modern EGR system is illustrated in Figure 7.
Figure 5. Overview of the dynamic model of a diesel engine equipped with common rail FIE. In more detail, the model becomes:
Intercooler Supplv
I
EGR valve
q i ~ t ili~ #
Figure 7. An illustration of a High pressure EGR system
Figure 6. The common rail system with a more detailed presentation of the dynamic elements.
Exhaust gas is circulated on the high pressure side of the boost pressure system and is regulated by both an EGR valve and a variable geometry turbocharger.
R. K. Stobart et al. / Annual Reviews in Control 23 (1999) 109-116
This is a complex system with two primary control inputs and two controlled outputs : EGR rate and manifold pressure. The precise interface between engine and control simulation requires careful formulation to get the best from both tools. One approach may be as illustrated in Figure 8 : $imulink
EGR demand
115
of control systems for engines, both diesel and spark ignition. The application of controls related functions allows the scope of the detailed engine simulation code (GT-Power) to be considerably enhanced. The overall effect of this modelling architecture is to make the engine model more accessible to controls system development and to offer controls design tools to powertrain engineers. This is a welcome effect of creating a means of communication.
Load demand
Perhaps the most significant effect of CPower is to reduce risk in the design, development and evaluation of control systems. While this is a general attribute, the particulars include the co-engineering of controls and their calibration with the engine.
Figure 8. The structure of a Simulink/GT-Power model for EGR control This approach considers both EGR and air flow as independent parameters. In practice the air flow would be set by another control algorithm responsible for load control. The two separate loops controlling respectively air flow and air-fuel ratio are supplemented by a model which predicts the behaviour of the EGR system. This model is used to preset the EGR and VGT valve positions in a feedforward sense. Within the control simulation package it is also necessary to model the dynamics Of the valves. Here the simulation might also use the drive voltages or pneumatic pressure available to drive the valves. The engine simulation code will simulate the complex gas dynamics and heat transfer associated with the EGR sub-system. The interface again is quite clean, and leaves the controls specialist able to concentrate on the control design requirements. 7. CONCLUSIONS DEVELOPMENTS.
AND
Future needs are dominated by new engine combustion systems and the "sensing" of new phenomena. Examples include gasoline direct injection, use of knock as a feedback parameters and the use of parameters derived from cylinder pressure. Conceptual new sensors will include burn rate and fast NOx sensors. Armed with this approach, such schemes can be investigated in detail and early decisions made about their viability without excessive engineering expenditure. REFERENCES Atkins, R A, Lee-Chung, E, and Taylor H F (1995). Fiber Optic In-Cylinder Pressure Sensor Developed, Diesel and Gas Turbine Worldwide, April 1995, Vol 27, No 3, ppl6b-16d Bennington, H D (1956). Production of Large Computer Systems, Proceedings ONR, Symposium on Advanced Programming Methods for Digital Computers, June 1956 Boehm, B W (1988). A Spiral Model of Software Development and Enhancement, IEEE Computer, May 1988 Hendricks E (1989). The Analysis of Mean Engine Models, SAE 890563
FURTHER
Lukich, M (1997). Rapid Prototyping of Embedded Systems : 1997 Update, SAE 97EIC-17.
CPower represents a significant step in the development of accessible tools for the development
Powell J D (1993). Engine Control Using Cylinder Pressure : Past, Present and Future, Journal of
116
R. K. Stobart et al. /Annual Reviews in Control 23 (1999) 109-116
Dynamic Systems, Measurement and Control, June 1993, Vol 115, pp343-350 The STARTS Guide to methods and software tools for the construction of large real time systems, NCC Publications, Hobbs Southampton, 1987 Weeks, R and Moskwa, J (1995). Automotive Engine Modelling for Real Time Control Using Matlab/Simulink, SAE 950417