H
Model-Based Design

KEY ELEMENTS OF MODEL-BASED DESIGN

Model-based design (MBD) is a mathematical and visual method of addressing the problems associated with designing complex control systems and is being used successfully in many motion control, industrial equipment, aerospace, and automotive applications. It provides an efficient approach for the four key elements of the development process cycle: modeling a plant (system identification), analyzing and synthesizing a controller for the plant, simulating the plant and controller, and deploying the controller—thus integrating all of these multiple phases and providing a common framework for communication throughout the entire design process.

This MBD paradigm is significantly different from the traditional design methodology. Rather than using complex structures and extensive software code, designers can now define advanced functional characteristics using continuous-time and discrete-time building blocks. These built models along with some simulation tools can lead to rapid prototyping, virtual functional verification, software testing, and validation. MBD is a process that enables faster, more cost-effective development of dynamic systems, including control systems, signal processing, and communications systems. In MBD, a system model is at the center of the development process, from requirements development, through design, implementation, and testing. The control algorithm model is an executable specification that is continually refined throughout the development process.

MBD allows efficiency to be improved by:

  • Using a common design environment across project teams

  • Linking designs directly to requirements

  • Integrating testing with design to continuously identify and correct errors

  • Refining algorithms through multidomain simulation

  • Automatically generating embedded software code

  • Developing and reusing test suites

  • Automatically generating documentation

  • Reusing designs to deploy systems across multiple processors and hardware targets

The different phases of MBD are indicated in Figure H-1. Throughout the different phases of MBD, several levels of modeling are required, both from the plant and the control points of view, in order for the functional behavior of the model to match that of the generated code. Figure H-2 shows an example of different levels used for different applications.

METHODOLOGY

This section explains different processes used as part of the MBD approach.

The first step is the simulation (Figure H-3), where neither the controller nor the plant operates in real time. This step, usually used toward the beginning of the process, allows engineers to study the performance of the system and design the control algorithm(s) in a virtual environment, by running computer simulations of the complete system, or subsystem.

Rapid control prototyping (RCP) is a process that lets the engineer quickly test and iterate control strategies on a real-time computer with real input/output devices RCP (see Figure H-4) differs from (HIL) hardware-in-the-loop in that the control strategy is simulated in realtime and the “plant,” or system under control, is real. RCP is now the typical method used by engineers to develop and test their control strategies. It was first used to develop power train control strategies. The simple reason is that the control software, which is in the engine and transmission control units, is difficult and time consuming to modify. It has since been adopted industry wide in applications such as antilock braking, antiroll, vehicle stability, active cruise control, and torque distribution.



The National Academies | 500 Fifth St. N.W. | Washington, D.C. 20001
Copyright © National Academy of Sciences. All rights reserved.
Terms of Use and Privacy Statement



Below are the first 10 and last 10 pages of uncorrected machine-read text (when available) of this chapter, followed by the top 30 algorithmically extracted key phrases from the chapter as a whole.
Intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text on the opening pages of each chapter. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

Do not use for reproduction, copying, pasting, or reading; exclusively for search engines.

OCR for page 227
H Model-Based Design KEY ELEMENTS OF MODEL-BASED DESIGN • Automatically generating documentation • Reusing designs to deploy systems across multiple Model-based design (MBD) is a mathematical and visual processors and hardware targets method of addressing the problems associated with designing complex control systems and is being used successfully in The different phases of MBD are indicated in Figure H-1. many motion control, industrial equipment, aerospace, and Throughout the different phases of MBD, several levels of automotive applications. It provides an efficient approach modeling are required, both from the plant and the con- for the four key elements of the development process cycle: trol points of view, in order for the functional behavior modeling a plant (system identification), analyzing and syn- of the model to match that of the generated code. Fig - thesizing a controller for the plant, simulating the plant and ure H-2 shows an example of different levels used for dif- controller, and deploying the controller—thus integrating all ferent applications. of these multiple phases and providing a common framework for communication throughout the entire design process. METHODOLOGY This MBD paradigm is significantly different from the traditional design methodology. Rather than using complex This section explains different processes used as part of structures and extensive software code, designers can now the MBD approach. define advanced functional characteristics using continuous- The first step is the simulation (Figure H-3), where nei- time and discrete-time building blocks. These built models ther the controller nor the plant operates in real time. This along with some simulation tools can lead to rapid proto- step, usually used toward the beginning of the process, al- typing, virtual functional verification, software testing, and lows engineers to study the performance of the system and validation. MBD is a process that enables faster, more cost- design the control algorithm(s) in a virtual environment, by effective development of dynamic systems, including control running computer simulations of the complete system, or systems, signal processing, and communications systems. In subsystem. MBD, a system model is at the center of the development Rapid control prototyping (RCP) is a process that lets process, from requirements development, through design, the engineer quickly test and iterate control strategies on implementation, and testing. The control algorithm model a real-time computer with real input/output devices RCP is an executable specification that is continually refined (see Figure H-4) differs from (HIL) hardware-in-the-loop throughout the development process. in that the control strategy is simulated in realtime and the MBD allows efficiency to be improved by: “plant,” or system under control, is real. RCP is now the typical method used by engineers to develop and test their • Using a common design environment across project control strategies. It was first used to develop power train teams control strategies. The simple reason is that the control • Linking designs directly to requirements software, which is in the engine and transmission control • Integrating testing with design to continuously identify units, is difficult and time consuming to modify. It has since and correct errors been adopted industry wide in applications such as antilock • Refining algorithms through multidomain simulation braking, antiroll, vehicle stability, active cruise control, and • Automatically generating embedded software code torque distribution. • Developing and reusing test suites 

OCR for page 227
 TECHNOLOGIES AND APPROACHES TO REDUCING THE FUEL CONSUMPTION OF MEDIUM- AND HEAVY-DUTY VEHICLES FIGURE H-1 V diagram for software development. Figure 2-16 ,,V% diagram for software development.eps bitmap FIGURE H-2 Different levels of modeling required throughout the model-based design process. Figure H-2 Different levels of modeling required throughout.eps bitmap--resolution is degraded

OCR for page 227
 APPENDIX H FIGURE H-3 Simulation. Figure H-3 Simulation.eps bitmap FIGURE H-6 Production code generation. Figure H-6 Production code generation.eps bitmap FIGURE H-4 Rapid control prototyping Figure H-4 Rapid control prototyping.eps bitmap FIGURE H-7 Software-in-the-loop. Figure H-7 Software in the loop.eps bitmap FIGURE H-5 On-target rapid prototyping. Figure H-5 On-target rapid prototyping.eps bitmap For the on-target rapid prototyping case (see Figure H-5), FIGURE H-8 Processor-in-the-loop new or modified functionality is added to the production Figure H-8 Processor in the loop.eps code in the controller-embedded target processor to verify the additions/changes. bitmap Once all the functions have been developed and tested, the net. In this case, no input/output devices are used for the production code is finally implemented (see Figure H-6). communication. In the software-in-the-loop (SIL) phase (see Figure H-7), HIL (see Figure H-9) is a technique for combining a math- the actual production software code is incorporated into the ematical simulation model of a system with actual physical mathematical simulation that contains the models of the hardware, such that the hardware performs as though it were physical system. This is done to permit inclusion of software integrated into the real system. For testing and development functionality for which no model(s) exists or to enable faster of embedded electronic controllers, the hardware controller simulation runs. and associated software are connected to a mathematical During the processor-in-the-loop phase (see Figure H-8), simulation of the system plant, which is executed on a the control is compiled and downloaded into an embed- computer in real time. To connect the real-time model to ded target processor and communicates directly with the the hardware controller, the real-time computer receives plant model via standard communications such as Ether- electrical signals from the controller as actuator commands

OCR for page 227
0 TECHNOLOGIES AND APPROACHES TO REDUCING THE FUEL CONSUMPTION OF MEDIUM- AND HEAVY-DUTY VEHICLES that would be controlled to represent the rest of the vehicle losses. Figure H-11 shows a similar approach using a battery and a DC supply source emulating the remainder of the vehicle. In both cases the hardware component will be the one that (1) represents the new technology or (2) has not been properly validated yet or (3) cannot be accurately modeled (e.g., due to transients or thermal issues). It should also be noted that more than one component can be hardware while some of them are still emulated. For ex- ample, both an engine and a battery could be hardware while the rest of the power train and the vehicle are emulated. One of the issues in using that approach, however, is the potential FIGURE H-9 Hardware-in-the-loop. for communication-related delays since some of the signal Figure H-9 Hardware in the loop.eps transfer most likely has to go through the Internet. bitmap An approach to characterize a system using several hardware components without building the entire vehicle is to drive the plant and converts these signals into the physi- shown in Figures H-12 and H-13. The Modular Automotive cal variables connected to the plant model. The plant model Technology Testbed (MATT) has been developed to easily calculates the physical variables that represent the outputs replace components by switching different plates. In the of the plant, which are converted into electrical signals that example below, a pretransmission parallel hybrid is shown. represent the voltages produced by the sensors that feed the This concept allows the entire power train (or most of it) on controller. a rolling chassis dynamometer in a controlled environment. Another option to evaluate fuel consumption is compo- However, like most approaches, it also shows some limita- nent-in-the-loop (CIL), a combination of HIL and RCP. In tions, including lack of under-hood thermal management CIL, an entire system is connected to a source emulating or the presence of a T-shaped reduction box to connect the the rest of the vehicle. For example, Figure H-10 shows an wheels. engine and its controller connected to an AC dynamometer FIGURE: H-10 Engine on dynamometer. SOURCE: Courtesy of Cummins. Figure H-10 Engine on dynamometer.eps bitmap

OCR for page 227
 APPENDIX H FIGURE H-11 Battery connected to a DC power source. SOURCE: Argonne National Laboratory. Figure H-11 Battery connected to a DC power source.eps bitmap FIGURE H-12 Several components in the loop—MATT example. SOURCE: Argonne National Laboratory. gure H-12 Several components in the loop MATT example.eps bitmap--legibility is degraded FIGURE H-13 Mixing components hardware and software—MATT example. SOURCE: Argonne National Laboratory. Figure H-13 Mixing components hardware and software-MATT exa.eps bitmap

OCR for page 227
 TECHNOLOGIES AND APPROACHES TO REDUCING THE FUEL CONSUMPTION OF MEDIUM- AND HEAVY-DUTY VEHICLES PROCESS SELECTION • Test facility to test facility ariability. A 2002 report from the Automotive Testing Laboratory [source CRC Different processes can be used to provide inputs for E-55-1 Inter-laboratory Crosscheck of Heavy-Duty regulation depending on the technology considered and the Vehicle D.PDF] highlights the discrepancies between degree of validation of the models. Ideally, if all the mod- several vehicle testing facilities. Figure H-15 shows els have been thoroughly validated, one would like to only significant differences among the six laboratories. The perform simulations to provide regulatory inputs. Realisti- main difference (Lab C) is mainly due to high-altitude cally, since the state-of-the-art models do not yet fulfill all impact, while the smaller discrepancies among the engineering expectations (e.g., engine emissions or cold other laboratories are related to a series of reasons start), a combination of hardware and software will most ranging from testing process to road load curve to certainly have to be used for the foreseeable future. A couple driver technique. However, it should be noted that for of examples highlighting the potential use of each process the truck employed, particulate matter (PM) was a spe- are given in Figure H-14. cies that is far more sensitive to test conditions than fuel use. UNDERSTANDING UNCERTAINTIES • Test-to-test ariability. While the testing conditions (e.g., temperature, humidity) are maintained constant To select a process to properly characterize a particular during testing, several other factors affect dynamom- technology, it is compulsory to understand and quantify the eter test results. One of the main factors is due to the uncertainties associated with each process. Examples of driver, whether related to gear selection or engine questions that need to be addressed within each process and on/off for hybrid vehicles. It is important to note that in between processes are given below. the driver model chosen in simulations will also affect results and is more repeatable than a human driver Process Uncertainty but must be chosen to be representative of a human driver. Uncertainty resides within each process and should be While the impact can be important for conventional properly quantified. The following provides some examples vehicles, especially when using manual transmissions, for different processes. it is even more so for hybrid electric vehicles, due to —If several models have not been validated for the test Vehicle conditions (e.g., cold star t, AC on, and so on), vehicle Testing testing is required. —Data collection for model validation. —If vehicle model has been validated, evaluate engine Component emissions or cold-star t fuel efficiency over a drive cycle. in the Loop —If vehicle model and engine plant have been validated, Hardware use a new production engine controller to evaluate vehicle in the Loop fuel efficiency over a drive cycle. Rapid —Use engine hardware and emulated controller if the main Control modification is related to hardware. Prototyping —If all models are validated (e.g., through use of production code for controllers and detailed plant models) and change Software in vehicle characteristics does not require any fur ther in the Loop validation (e.g., final drive ratio). FIGURE H-14 Example of potential process use.

OCR for page 227
 APPENDIX H FIGURE H-15 Mean particulate matter results with two standard deviation error bars. SOURCE: Argonne National Laboratory. Figure H-15 Mean par ticular matter results with two standard.eps bitmap--degraded legibility conditions at which these parameters are measured the sensitivity of the engine on/off related to the pedal along with the instrumentation will influence the position. uncertainty of the final simulations. As such, charac- • Delay impact. For several processes that include a terization of the parameters for several systems should mix of hardware and software, including CIL, SIL, or be clearly defined. This would include rigorous evalu- HIL, delays introduced by some hardware on the com- ation protocols for the evaluation of coefficients for mand and feedback can significantly affect the results. tire rolling resistance and aerodynamic drag to ensure Dynamometer slew rate and command methodology consistency and minimize uncertainty. (e.g., analog, digital, CAN) are some of the examples to be addressed. Such delays over an entire drive cycle In addition, even if using more detailed models (e.g., could lead to several percentage point differences in zero-dimensional engine model rather than steady state) can energy, which would impact the results for both fuel lead to better representation of the transients, such models efficiency and emissions. As a result, levels of accept- do require significantly more testing and data collection to able delays should be defined for each process and properly represent the system. As such, a trade-off analy- potentially each technology to provide a low level of sis should be performed to evaluate the additional testing uncertainties. required to populate the detailed models compared to the • Appropriate selection of leel of modeling. To simulate added accuracy they provide. This accuracy evaluation may specific phenomena properly, an appropriate level of be dependent on the evolutionary stage of the technology and modeling must be selected. As such, engineers do not cannot be considered static. use the same models at the beginning of a project to compare different power train configurations as toward the end of a project when the focus is on drive quality In-between Processes and emissions. For regulatory purposes, the approach When selecting a process, it is important to understand the might be similar. The committee recommends that a uncertainties introduced by the methodology employed. For study should be conducted to assess the uncertainty example, using an engine on the dynamometer (CIL) versus between different levels of modeling for specific com- testing the entire vehicle will lead to differences in results as ponents. they each have different uncertainty sources. While the driver • Data collection for model instantiation. For the models will have the largest impact on the results during chassis dy- to represent technologies properly, it is necessary to namometer testing, the driver is not a factor anymore during populate them with accurate sets of parameters. The

OCR for page 227
 TECHNOLOGIES AND APPROACHES TO REDUCING THE FUEL CONSUMPTION OF MEDIUM- AND HEAVY-DUTY VEHICLES the CIL process, where delays and model uncertainties ac- subsystems, systems, or vehicles. A report should be count for most of the uncertainties. As a result, it is important provided to the regulatory agency demonstrating the to quantify each process, as one might not necessarily lead process and the results of the validation. This report to greater uncertainties than another one. could be generic and automatically developed based on the list of required parameters or comparisons for the regulation. Need for Process Standardization • Appropriate modeling leel. Using wrong assumptions As shown in Figure H-16, each process should be stan- can lead to erroneous conclusions; errors can come dardized, from data gathering to model validation and report- from modeling assumptions or from data. To answer ing of results. the right questions, users need to have the right mod- eling tools. For instance, one common mistake is to • Hardware set-up process. For any process involving study engine emissions by using a steady state model hardware, from HIL to RCP or vehicle testing, detailed or to study component transient behavior by using a test procedures should be developed to ensure consis- backward model. A study providing general guidance tency across organizations. While some work has been would accelerate development of the required mod- performed for vehicle testing, little to no work has been els. done for HIL and RCP, and more work is required to • Regulatory report. Since the results must be approved validate or improve vehicle test protocols. for regulatory purposes, a generic report should be • Validation process. From a modeling point of view, defined so that every original equipment manufacturer a critical need is to define what validation means and provides the same information. This report or set of how it should or could be quantified. While all engi- reports would include not only the results but also neers claim their models are validated, the assumptions the assumptions and details of the simulations or tests behind each one can vary significantly. for selected critical parameters to ensure validity and A detailed process should be developed, describing consistency of the results. what tests should be performed to validate specific Model/Hardware Exercising Model Development Component Testing Hardware Set-up for Data Collection Process Component Testing Test Procedure for Validation Process Component Data Collection/ Validation Instrumentation Vehicle Results Validation Repor ting FIGURE H-16 Main phases requiring standardized processes.