
small (250x250 max)
medium (500x500 max)
large ( > 500x500)
Full Resolution


i Analysis Tool for Fuel Cell Vehicle Hardware and Software ( Controls) with an Application to Fuel Economy Comparisons of Alternative System Designs By Karl Heinz Hauer Dipl. Ing. ( University of Braunschweig, Germany) 1990 Dissertation Submitted in partial satisfaction of the requirements for the degree of Doctor of Philosophy in Transportation Technology and Policy in the Office of Graduate Studies of the University of California Davis Approved: Committee in Charge 2001 ii Meinem Vater iii Table of Content 1. INTRODUCTION AND PROBLEM CONTEXT .................................................................... 1 2. LITERATURE REVIEW........................................................................................................ 5 2.1. Introduction................................................................................................................... ................... 5 2.2. Survey and Discussion of the existing vehicle models .................................................................. 11 2.2.1. The HY ZEM ( Hybrid Zero Emission Mobility) Model .......................................................... 14 2.2.2. The PNGVSAT ( Program for New Generation Vehicles Systems Analysis Toolkit) Model... 18 2.2.3. The Advisor ( Advanced Vehicle Simulator) Model ................................................................. 26 2.2.4. The UC Davis Hydrogen ( 1998 Version) Model...................................................................... 32 2.2.5. The Simplev ( Simple Electric Vehicle Simulation) Model....................................................... 36 2.3. Summary........................................................................................................................ ................. 38 3. APPLIED MODELING METHODOLOGY .......................................................................... 44 3.1. General Aspects........................................................................................................................ ...... 44 3.2. Mathematics ............................................................................................................................... .... 46 3.2.1. Introduction................................................................................................................... ........... 46 3.2.2. Example and Transfer into SIMULINK.................................................................................... 56 4. MODEL DESCRIPTION...................................................................................................... 58 4.1. Modeling Structure and Goals....................................................................................................... 58 4.2. Vehicle Model.......................................................................................................................... ....... 60 4.2.1. Drive Cycles and Driver Model ................................................................................................ 61 4.2.2. Physical Vehicle Model ............................................................................................................ 66 4.3. Component Models ......................................................................................................................... 73 4.3.1. Electric Motor Including Power Electronic .............................................................................. 73 4.3.2. Motor Controller and Motor Control Algorithm....................................................................... 82 4.3.3. Transmission................................................................................................................... ......... 90 4.3.4. Fuel Cell System....................................................................................................................... 94 4.3.5. Battery System........................................................................................................................ 128 4.3.6. Ultra Capacitor System........................................................................................................... 140 4.3.7. DC DC Converter ................................................................................................................... 154 4.3.8. Vehicle Controller................................................................................................................... 173 5. MODEL APPLICATION.................................................................................................... 179 5.1. Vehicle Requirements................................................................................................................... 179 5.2. Vehicle Parameters and Vehicle Design...................................................................................... 181 5.3. Component Sizing ......................................................................................................................... 189 5.3.1. Choice and Sizing of the Battery System................................................................................ 189 5.3.2. Choice and Sizing of the Ultra capacitor System ................................................................... 191 iv 5.4. Simulation Results ........................................................................................................................ 197 5.4.1. Load Following Fuel Cell Vehicle Model............................................................................... 198 5.4.2. Battery Hybrid Fuel Cell Vehicle Model ................................................................................ 207 5.4.3. Ultra Capacitor Hybrid Fuel Cell Vehicle Model ( indirect coupling) .................................... 221 5.4.4. Ultra Capacitor Hybrid Fuel Cell Vehicle Model ( direct coupling) ....................................... 228 5.5. Summary of the Simulation Results ............................................................................................ 234 6. VERIFICATION OF THE RESULTS................................................................................. 239 7. SUMMARY AND CONCLUSION ..................................................................................... 245 8. REFERENCES.................................................................................................................. 249 9. APPENDIX....................................................................................................................... 255 9.1. Forwards and Backwards Looking Modeling Approach .......................................................... 255 9.2. Method of Co Simulation ............................................................................................................. 261 9.3. Rapid Prototyping.................................................................................................................... .... 267 9.4. Conversion Factors ....................................................................................................................... 268 9.5. Vehicle Parameters ....................................................................................................................... 269 9.6. Battery and the Battery Controller Parameters......................................................................... 271 9.7. Ultra Capacitor Parameters for the Directly to the Stack Coupled Ultra Capacitor............. 272 9.8. Ultra Capacitor Parameters for the Via Dc Dc Converter to the Stack Coupled Ultra Capacitor ............................................................................................................................... ................... 274 1 1. Introduction and Problem Context The ever growing demand for individual transportation leads to a larger and larger vehicle fleet and a steady increase in vehicle miles traveled ( VMT) ( National Research Council, 1997). Associated with this increase in VMT are increases in air pollution and carbon dioxide emissions, one possible reason for the observed global warming phenomena ( The International Panel on Climate Change, 1995). Although emissions from new conventional vehicles with internal combustion engines and hybrid vehicles with internal combustion engines and additional electric motors are reduced, the air quality standards are not in attainment with federal regulations in many regions in the United States. Especially on the west coast in California with its rapid growth, booming economy, and special weather conditions that promote the formation of ozone, cities like Los Angeles and San Diego battle severe air quality problems ( Lloyd, 1999). In addition, the energy efficiency and related carbon dioxide emissions are still far from the 80 miles/ gallon goal for passenger vehicles set by the Partnership of New Generation Vehicles ( PNGV) and seem to be difficult to achieve with conventional technology. Widely discussed among the alternatives to the internal combustion engine vehicle are fuel cell vehicles. This vehicle type promises not only very clean operation ( up to zero emission operation, but also higher energy efficiency than conventional vehicles without the range limitations associated with battery electric vehicles. 1 Although the fuel cell vehicle has been discussed since the 60’ s ( Sievert 1968), fuel cell vehicles have not been seen as a likely replacement for the internal combustion engine vehicle until recently. In 1994 Daimler Chrysler ( formerly Daimler Benz) introduced the first 2 New Electric Car ( NeCar 1) in a series of five prototype fuel cell vehicles ( Daimler Chrysler 1999). Despite the fact that these vehicles have prototype characteristics they demonstrated one path to a more environmentally friendly passenger vehicle and sparked public interest and a race into the market. Today all major car companies are investing heavily in this new and promising technology with ambitious plans to introduce it into the market ( Panik 1999, GM Europe 1999). Fuel cell vehicle modeling is one method for systematic and fast investigation of the different vehicle options ( fuel choice, hybridization, reformer technologies). However, a sufficient modeling program, capable of modeling the different design options, is not available today. Shortfalls of the existing programs, initially developed for internal combustion engine hybrid vehicles, are: • Insufficient modeling of transient characteristics; • Insufficient modeling of advanced hybrid systems; • Employment of a non causal ( backwards looking) structure; • Significant shortcomings in the area of controls. Modern simulation programs should be capable of serving as tools for analysis as well as development. In the area of analysis, a modeling tool for fuel cell vehicles needs to address the transient dynamic interaction between the electric drive train and the fuel cell system. Especially for vehicles lacking an instantaneously responding on board fuel processor, this interaction is very different from the interaction between a battery ( as power source) 1 Besides hydrogen fueled fuel cell vehicles, battery electric vehicles are the only other zero emission technology available today. 3 and an electric drive train in an electric vehicle design. Non transient modeling leads to inaccurate predictions of vehicle performance and fuel consumption. Applied in the area of development, the existing programs do not support the employment of newer techniques, such as rapid prototyping. This is because the program structure merges control algorithms and component models, or different control algorithms are lumped together in one single control block and not assigned to individual components as they are in real vehicles. In both cases, the transfer of control algorithms from the model into existing hardware is not possible. The simulation program developed in this dissertation recognizes the dynamic interaction between fuel cell system, drive train and optional additional energy storage. It provides models for four different fuel cell vehicle topologies: • A load following fuel cell vehicle; • A battery hybrid fuel cell vehicle; • An ultra capacitor hybrid fuel cell vehicle in which the ultra capacitor unit is coupled via a dc dc converter to the stack; • An ultra capacitor hybrid fuel cell vehicle with direct coupling between fuel cell stack and ultra capacitor. The structure of the model is a causal and forward looking. The model separates the modeling of control algorithms from the component models. The setup is strictly modular and encourages the use of rapid prototyping techniques in the development process. 4 The first half of the dissertation explains the model setup. In the second half of the dissertation, the simulation of different hybrid vehicle designs illustrates the capabilities of the model. This study shows that, from the standpoint of fuel economy improvement, hybrid fuel cell vehicles have a potential advantage over the pure load following fuel cell vehicle. Further, the study shows that among the modeled hybrid vehicles the vehicle with directly to the stack coupled ultra capacitor shows the largest benefit in terms of fuel economy compared to the pure load following design. An additional benefit of this design is that it is the simplest of the three investigated hybrid vehicle concepts. For all of the analyzed hybrid vehicles, the improvement of fuel economy results from the ( averaged over a drive cycle) higher fuel cell system efficiency and the additional feature of regenerative braking. Besides the arrangement of the components, the realized fuel economy benefits depend significantly on the control schemes balancing vehicle performance, fuel cell system characteristics, and stress of the energy storage system. Due to the limited energy storage capacity of the ultra capacitor systems, the two vehicles hybridized with ultra capacitors are especially sensitive to the design of the control algorithms. In addition to the potential improvement of fuel economy, hybrid designs offer the possibility to relax the transient requirements for the fuel cell system and the feature of a rapid cold start in the morning ( increased customer benefit). Although not investigated, each of these two advantages is considered important and could, together with the higher fuel economy, spark the interest in hybrid fuel cell vehicle designs in the near future. 5 2. Literature Review This chapter analyses different fuel cell vehicle models and compares them with each other on a qualitative basis. Quantitatively Hoefgen ( Hoefgen 2001) compares a subset of the models listed in Table 2 3. For the qualitative comparison in this dissertation work first a metric of comparison was established. Second the most commonly discussed models are listed and relationships are identified. Based on the metric of comparison five of the listed modeling programs are described and advantages and disadvantages are highlighted. The comparison concludes that none of the investigated models is satisfactory in terms of modularity ( separation of controls and component models), vehicle configurations modeled, and dynamic capabilities. 2.1. Introduction The generic requirements for a fuel cell fuel vehicle model can be defined as follows and are not different to the requirements of other types of modeling work2. A fuel cell vehicle model has to be physically and mathematically sound. All relevant physical effects have to be considered and the model should stand on mathematical solid ground. Unless these two conditions are fulfilled we cannot rely on the results. In addition to the soundness the scope of the model should also be complete. Complete in this context means that it should enable the modeling of different types of vehicles ( hybrids, non hybrids and different forms of hybrids) and fuel cell systems for different fuels. The resolution of the modeling effort should be high enough to capture all the effects of interest. For example some of the models listed in Table 2 3 simplify the 6 function of regenerative braking so much that the results become extremely inaccurate. In the context of Table 2 1, the resolution or depth of modeling these models provide is not sufficient. Also a fuel cell vehicle model has to be flexible enough to incorporate new trends and technologies without the need of starting from scratch. From a practical point of view: the necessary input data have to be available, the validation of the model should be possible, and the model should support its use as well as the issue of program maintenance. The runtime should be in context of the problem setup. Therefore for more complex questions a longer runtime seems to be acceptable. Last, but not least, the results have to be valid and ( within tolerances) match the experimental results. • Theoretically sound o Physically o Mathematically • Complete scope o Consideration of different vehicle and fuel cell system concepts o Resolution ( are all effects of interest modeled in a sufficient detail) o Flexibility ( is the model flexible enough to incorporate future developments) • Practicality o Are the required input data available? o Validation possible? o Ease of operation o Ease of program maintenance? ( Logical structure) o Runtime • Valid results Table 2 1: Generic modeling requirements 2 The listed requirements are basically taken from John L. Bowman and Moshi Ben – Akiva’s paper “ Activity  Based Travel Forecasting” ( Bowman and Akiva, 1996) but translated into the context of this dissertation work. 7 Requirement Criteria Theoretical soundness Is the model programmed in a forward or backwards approach? 3 Complete Scope • Completeness Is the model employing techniques supporting the coverage of a wide range of vehicle concepts ( scaling, component libraries)? 4 • Resolution Does the model support the method of co simulation? • Flexibility Is the model programmed in a modular way? 5 Practicality • Input data Are all required input data available? • Validation Does the program setup support the method of rapid prototyping? Are component models separated from control algorithms? • Ease of use Is a graphical user interface programmed? Is the documentation complete and useful? Is the runtime reasonable? Is the setup of the model transparent and logical? Valid results All the models investigated in this paper deliver valid results within tolerances. Therefore this requirement is not a measure of comparison. Table 2 2: Translation of the original requirements into objective criteria that could be checked For an objective comparison of the different simulation models the list of requirements in Table 2 1 is not beneficial. Therefore the content of Table 2 1 is translated into a number of key criteria that a “ good” fuel cell vehicle modeling program 3 Limiting the requirement of theoretical soundness to the criteria above assumes that the model does not violate any elementary physical or mathematical laws. This assumption is justified for all of the models looked at in this dissertation. 4 The issue of completeness looks towards the potential of a model to be complete, e. g.; the coverage of all vehicle configurations of interest. Because of the number of possible configurations and the unpredictability of future developments completeness is fulfilled if the model structure supports measures to incorporate a large number of designs. 8 has to fulfill ( Table 2 2). The comparison is looking at these criteria assuming that the incorporation of them into the program guarantees the original requirements in Table 2 1. This systematic comparison emphasizes the ( theoretical) potential of the simulation programs. This first comparison will be supported by a closer look at how much of the theoretical potential has already been realized in the current version of each model. This second measure of comparison is more subjective because of fact that due to the very different modeling approaches a direct comparison of functionality is not possible. However it still provides significant insight into the current state of fuel cell vehicle modeling. After establishing the method of comparison the following paragraphs list the most important ( and most used) electric, hybrid and fuel cell vehicle modeling programs. Among them only the UC Davis hydrogen fuel cell vehicle model has been exclusively developed for fuel cell vehicle modeling. All the other programs incorporate functionality for the simulation of battery electric and IC hybrid vehicles. 5 Flexibility describes the possibility to change the model structure in a time efficient manner. A modular structure supports flexibility. 9 Table 2 3: Overview about alternative fuel vehicle models In addition to the vehicle models listed in Table 2 3 other models are under development or already completed. Most of these other, not listed, models are either propriety and internally developed by automotive manufacturers or contractors and only very limited information is publicly available or they are not completed yet. For this reason these models are not discussed in this dissertation work. The next section compares the most important models listed in Table 2 3 with regard to the criteria explained in the appendix and derives, based on this comparison, the need for a new vehicle model that will be described in this dissertation work. The comparison ends in a summery and concludes that a new fuel cell vehicle model is necessary. Name Source Backwards/ Forwards Fuel Cell Vehicles ? Year HYZEM Ricardo Consulting Engineers Ltd. Forward No 1995 Elvis Southwest Research Institute Backwards No 1993 Path Southwest Research Institute Forward No 1996 1997 PSAT Southwest Research Institute and Argonne National Laboratories Forward Yes 1996 1999 Advisor National Renewable Research Laboratory ( NREL) Backwards Yes 1994 2000 Simplev Idaho National Engineering and Environmental Laboratory Backwards No 1990 1997 Avte UC Davis, ITS Backwards No 1996 UC Davis – Hydrogen UC Davis, ITS Backwards Yes 1999 10 The appendix provides the necessary background information about three major issues associated with fuel cell vehicle modeling. They are closely tied to the list of model requirements at the beginning of the chapter and have their origin in this list. The issues discussed in the appendix are: • The choice of the modeling approach. Two different modeling approaches have been realized in the existing fuel cell vehicle models. The forwards looking and the backwards looking approach. The physical and mathematical soundness of the model is significantly depending on the choice of the modeling approach. • The incorporation of co simulation techniques. Co simulation techniques are the parallel operation of two different modeling programs, e. g. Matlab/ Simulink for the overall vehicle and Saber for the electric drive train within the vehicle. Co Simulation allows a higher depth of modeling or a higher resolution. • The incorporation of rapid prototyping and hardware in the loop features. Both methods are well known development techniques for shortening the development time. From a modeling point of view the benefits are the fact that ( through the involvement of the simulation program in the development process) a mutual validation of the model at all development stages occurs, and not only at the end of the development process. 11 2.2. Survey and Discussion of the existing vehicle models Five different development lines could be identified looking at the model properties and the historical development of the models ( Figure 2 1). These are: • Ricardo Consultants with the Hyzem program system ( Heath, 1996 and Sadler, 1998). • Southwest Research Institute ( SWRI) with the modeling program systems Elvis, Path, Apace and their final product PSAT ( McBroom, 1996). PSAT has been originally developed as the modeling tool for the Partnership of New Generation Vehicles but will be soon made publicly available from Argonne National Laboratory for registered researchers6. • National Renewable Energy Institute with the program system Advisor ( National Renewable Energy Laboratories, 2000). Since recently, Argonne National Laboratories is responsibility for the development lines PSAT and Advisor and incorporates them into a single graphical user interface for the ease of use. • UC Davis starting originally with the Advanced Vehicle Test Emulator ( AVTE) and an ( AVTE based) direct hydrogen fuel cell vehicle model ( Fuel Cell Modeling Group, 1999). Both models are derived from Advisor. In addition to this modeling effort, UC Davis started within the fuel cell vehicle modeling project a new forward looking fuel cell vehicle model that incorporates currently the fuels hydrogen, indirect methanol and indirect gasoline in hybrid and non hybrid versions. 6 The release, for registered researchers only, is scheduled for November 2000. 12 • Idaho National Engineering and Environmental Laboratory ( INEEL) with Simplev. The program has only historical meaning  it was phased out in 1997 ( Idaho National Engineering and Environmental Laboratory, 1993). The final product of each of these development lines will be taken and benchmarked according to the criteria listed in Table 2 2. In addition the fuel cell vehicle modeling capabilities will be listed qualitatively, e. g.; which type of fuel cell vehicle models are included ( hybrids, fuel choice). Finally a statement about the current stand of the model with respect to depth of analysis will be made. For example, some of the vehicle models include a static fuel cell system model based on maps only while other models take dynamic aspects into account. Based on this comparison it will be concluded that a new fuel cell vehicle simulation model is necessary. 13 Elvis 1990 1995 2000 Path Psat Apace Hyzem Simplev Generation 1 3 Advisor Generation 1 3 Avte DH2 INEEL IMFCV NREL UC Davis SWRI Ricardo merge 4 models remain Argonne National Lab. Figure 2 1: Model evolvement and history 14 2.2.1. The HY ZEM ( Hybrid Zero Emission Mobility) Model HY ZEM has been programmed by Ricardo Consultants and is not commercially available as an off the shelf programming package7. The program will always be delivered in a project specific form as part of a development contract. The model is programmed in Simulink in a causal, forward looking, approach ( Heath, 1996, Sadler, 1998). Figure 2 2 shows the program setup ( highest level) for the example of a series hybrid electric vehicle with internal combustion engine. The presence of a “ driver” block indicates the forward looking approach. Besides the driver the model consists of one main control Block “ SH controller” and component blocks for every major component. Each component model has three input and three output ports, each port could also be vectorized meaning it could combine several individual variables. The inputs and outputs are listed in Table 2 4. Control inputs and outputs are signals with no energy associated with them for example the value of a voltage or a current. Power outputs/ inputs connect blocks on the physical level. One example is the battery voltage connected to the motor block. This connection is physical and could therefore be seen in a real vehicle. The third pair of inputs/ outputs is also a physical connections but through these connections feedback loops among components are established. One example for such a feedback loop is the feedback of the motor current to the accessory block and finally to the battery block. Through these feedback loops dynamic behavior is incorporated into the model. Hyzem is set up in a modular form and includes a library for mechanical, electrical and control modules that all employ the same input / output 7 Personal email exchange with Ricardo Consultants in October 2000 15 structure ( Heath 1996). Input data for the modeling process are standard vehicle parameters and steady state maps for operating point dependent component properties ( Sadler, 1998). Input/ Output Label Comment Input 1 Controls input Signals from the controller block Input 2 Power input Input values from a previous block Input 3 Feedback input Feedback values from a connected block Output 1 Controls output Signals looped to the controls block Output 2 Power output Output values to a succeeding block Output 3 Feedback output Feedback values to a connected block Table 2 4: Overview of component models inputs and outputs. No information could be found about the possibility of co simulation. However in principle the causal, forward looking, approach supports co simulation. Also the program package “ wave” ( Ricardo Consultants, 2000) has been suggested by Ricardo Consultants to UC Davis for modeling the airside of a fuel cell system. Because of this suggestion it could be assumed that Ricardo also combines ( or attempts to combine) Hyzem and wave8. Because of the fact that the model is not off the shelf available, and is only provided as part of a larger contract, the issue of “ ease of use” becomes secondary. For example a graphical user interface, complete documentation and straight logic is not essential if the user gets assistance from Ricardo. The model has been validated with a Volkswagen Golf IC hybrid vehicle and a Peugot 106 electric vehicle ( Heath, 1996). 8 Personal email exchange between members of the fuel cell modeling group ( UC Davis) and Ricardo 16 Modeling results for an indirect methanol fuel cell vehicle in load following and load leveling ( hybrid) form have been presented by Sadler ( Sadler, 1998). The model includes start up characteristics and emissions although it is not clear how detailed the model is9. Strengths: • Strong modular approach using predefined components from a library ( Heath, 1996), • The model considers the dynamic interaction ( feedback) between components ( Heath, 1996). Weaknesses: • The combination of the library modules leads to a difficult to oversee system diagram, which does not always reflects the causalities within the vehicle. ( Example: In the electric vehicle model the battery voltage does not directly feed back into the motor block). • Control algorithms are not assigned to the individual components, such as the battery controller to the battery block. Instead the control algorithms are summarized in one single control block, which embeds the controls for all components. Embedding the controls of all components in one block makes rapid prototyping as one measure of continuous validation impossible10. However Ricardo claims that the recent versions are supporting rapid prototyping. • The levels of information flow and physical component interaction are not separated. 9 A version including fuel cell vehicle models was not available 10 This is true for the 1996 version of HYZEM. However for recent versions of HYZEM Ricardo Consultants claim the possibility of rapid prototyping. Because neither the software itself nor any detailed information has been made available the statements could not be verified. 17 Figure 2 2: Hyzem vehicle model ( most upper level of a series hybrid electric vehicle) vehicle vehicle traman traman motblack motblack loaaux loaaux genblack genblack engdiet engdiet battery Sum battery consh SH Controller Notes Driver & cycle 18 2.2.2. The PNGVSAT ( Program for New Generation Vehicles Systems Analysis Toolkit) Model The program PNGVSAT or PSAT has been originally developed by the Southwest Research Institute. Since August 2000 Argonne National Research Laboratories is responsible for program maintenance and further development. Since November 2000 PSAT 4.0 is available for registered researchers in the field of hybrid and electric vehicles ( Rousseau 2000). Figure 2 3 shows the most upper level of the model of an indirect methanol fuel cell vehicle with additional battery storage. The existence of a driver model ( the icon showing the steering wheel in Figure 2 3) indicates a causal, forward looking, modeling approach. The program documentation confirms the separation of driver and vehicle and the forward looking modeling approach ( Argonne National Laboratories 2000). The general structure is similar to the model developed by Ricardo Consultants. Specific similarities are: • A driver controls the velocity of the vehicle, • One single controls block organizes the component interaction ( Controller), • Each individual component block employs three inputs and three outputs, which could be interpreted identical to the inputs and outputs defined by Ricardo Consultants. However the labeling in PSAT is different and orientated to the physical value each port carries, e. g. the current going into the battery is labeled “ current in”, the resulting voltage at the battery terminals is labeled “ voltage out”. • Inputs and outputs of each block can be vectorized.. 19 Despite these similarities PSAT employs more blocks than Hyzem. While Hyzem employs only one block modeling the drive train between motor shaft and wheels PSAT uses four blocks for the same task. PSAT models this part of the drive train with much higher accuracy than all other models compared in this dissertation work. One example is tire slip including modeling weight transfer, a feature important for modeling vehicles that exhibit a high power – weight ratio, such as the EV1. The incorporation of advanced modeling techniques, such as co simulation is possible ( though not realized) in version 4.0. Although PSAT follows the general setup of Hyzem it does not strictly separate component models from control algorithms. Because of this PSAT 4 does not qualify for the employment of rapid prototyping. The fast and mutual validation of the program in parallel to the development process of a physical vehicle employing rapid prototyping is not possible. Another consequence of the mix of control algorithm with component models is that a validation on the component level is not possible. One example for this is the validation of the stand alone battery model. The battery model includes current limitations that are not part of the physical battery but realized in the motor controller software and power electronics. The effect is that even a short circuit of the battery model would not result in a voltage drop to zero volts and a current that exceeds the operational limits. In other words a largely oversized motor would still work fine with the battery without noticing that it draws a power much beyond what the battery is able to deliver. In fairness, is has to be said that PSAT as a complete model does not calculate anything wrong. However the result of the merge of a battery model with motor controller 20 characteristics is a difficult to oversee structure that makes changes and program maintenance time consuming. A helpful feature of PSAT is the graphical user interface ( Figure 2 4). This graphical user interface is very similar in appearance and logic to the one used in Advisor 3.0. It supports the following functions: • Choice of vehicle topology ( series, hybrid, conventional, split), • Choice of vehicle and component data, • Component choice ( a list of predefined components is available), • Component scaling ( battery, fuel cell system and electric motor), • Choice of control strategies, • Choice of drive cycle, • Parametric studies, • Display of results ( traces of values), • Summery of results. However the graphical user interface did not work in all cases and was therefore only of limited use. Also the use of a graphical user interface limits the flexibility of the program. A fuel cell system model is provided. It has the following characteristics: • The model covers warm up times and penalties associated with the warm up of the system. • Emissions are considered in the model but currently all data for modeling emissions are set to zero. 21 • Transient characteristics of the reformer are modeled with a first order transfer function. The stack characteristics are modeled using a one dimensional steady state lookup table. • The airside and water and thermal management characteristics are only considered through their impact on the overall fuel efficiency and transient effects are not taken into account. • In summery it could be said PSAT provides a fuel cell system placeholder model that mimics the effects of a fuel cell system  instead of a model based on fundamental principles. Strengths of PSAT are: • Availability of a large variety of vehicle concepts • Graphical user interface Weaknesses of PSAT are: • the merge of controls and component models, together with the not strict separation of functionality hurts rapid prototyping as one method of continuous validation • the merge of controls and component models does not allow validation on the component level • the merge of controls and component models lead to difficult to oversee interfaces and potentially problems in program maintenance and modifications 22 • The documentation references mostly to the graphical user interface. However many parts in the actual program are not explained11. 11 At the time of this dissertation the documentation was not finished yet. 24 workspace sum1 wh_ v01 veh_ v01 ptc_ series_ fc_ pos1_ au_ v01 mc_ v01 Disclosure main_ disclosure fd_ v01 fc_ v03 ess_ v01 drv_ v02 curves plot cpl_ v03 clock accelec_ v01 au_ v01 t_ hist info_ tx info_ wh info_ veh info_ ptc info_ mc info_ fd info_ fc info_ ess info_ drv info_ accelec info_ cpl 0 Figure 2 3: PSAT model ( most upper level) for the example of an indirect methanol fuel cell hybrid vehicle. 25 Figure 2 4: Graphical user interface PSAT. 26 2.2.3. The Advisor ( Advanced Vehicle Simulator) Model Advisor has been programmed by National Renewable Research Laboratory ( NREL) and is, after registration, freely available on the Internet ( National Renewable Research Laboratory, 2000). Figure 2 5 shows the most upper level of the Simulink code for the case of an indirect methanol fuel cell vehicle. The program is setup in a backwards approach, e. g. the model is not causal. However according to the Advisor online documentation Advisor labels itself as a hybrid backwards/ forwards approach. This name is confusing because it does not recognize the inherent non causality within the structure of the program, the key element of a backwards facing model as defined by Ricardo Consultants ( Heath, 1996), Southwest Research Institute ( Mc Broom, 1999) and Bengt Jacobson ( Jacobson, 1995) 12. As a consequence of the reverse causality the model is considered to be less physical and less mathematically sound. 13 Advisor is programmed in Matlab/ Simulink. However for special modeling aspects the program has been linked to several program tools. John A. MacBain provides in his paper “ Co Simulation of Advisor and Saber A Solution for Total Vehicle Energy Management Simulation” one example for co simulation of Advisor and Saber ( MacBain, 2000). However due to the reverse causality the employment of this method is limited. Furthermore MacBain describes the application of co simulation as the only solution for simulating the closely coupled mechanical and electrical systems in series hybrid vehicles. This is not true. The UC Davis hydrogen model allows the simulation of 12 Bengt Jacobson did not use the terms forward and backward looking models. Instead he used the terms driver controlled for the causal model and conventional model for the “ unnatural causality”. Important is that causality was his reason to distinguish both approaches. 27 this vehicle type without employing the method of co simulation ( UC Davis, Fuel Cell Modeling Team, 1998). This fundamental misjudgment can be taken as one indicator how confusing the reverse causality of Advisor and other backwards looking programs could be to users. From a practical point of view the reverse causality is one major obstacle that has been already pointed out14. The program compensates this partly with an extensive graphical user interface and a large component library. Because of these features the standard user is not required to look into the details of the model. The good online documentation also provides good support in application questions. However, whenever the model itself needs to be modified the user is required to follow the logic dictated by the reverse causality. This could become more challenging than the physical issues involved with the desired modification. Because of this the model is considered neither flexible nor transparent compared with forward looking models. The reverse causality makes the use of control algorithms for rapid prototyping approaches impossible. Therefore this method of mutual validation of the model is not available to the user. 13 See appendix. 14 See appendix. 28 Figure 2 5: Advisor model of an indirect methanol hybrid fuel cell vehicle wheel and axle < wh> vehicle < veh> gal total fuel used ( gal) power bus < pb> motor/ controller < mc> gearbox < gb> fuel cell control stategy < cs> fuel converter < fc> for fuelcell final drive < fd> exhaust sys < ex> energy storage < ess> drive cycle < cyc> fc_ emis ex_ calc t To Workspace Version & Copyright AND emis HC, CO, NOx, PM ( g/ s) Clock 29 Figure 2 6: Graphical User Interface ( GUI) of Advisor 3.0 0.15 0.15 0.2 0.25 0.25 0.3 0.25 30 According to the online documentation, Advisor provides direct hydrogen, directmethanol and indirect hydrocarbon fuel cell vehicle models. In the current version an indirect methanol system is not available ( August 2000, 3.0). The dynamic interaction among components, such as feedback effects, is limited. Subcomponents of the fuel cell system, such as the fuel reformer, air supply or water and thermal management are only modeled in terms of their impact on the net fuel cell system efficiency. Dynamic effects within the fuel cell system itself, such as reformer and air supply time lags, are not considered. For the case of the indirect hydrocarbon system emissions, are not predicted. Strengths: • The strength of advisor is the detailed graphical user interface ( Figure 2 6) that allows the setup and analysis of a wide range of vehicle configurations. The user can choose between 9 predefined drive train configurations. Each configuration allows the choice between 19 electric motors, 9 batteries and 7 fuel cell systems ( Wipke, 1999 and National Renewable Energy Laboratories, 2000). The mentioned components are scaleable and could be combined in a vehicle. The user interface is intuitive and provides rapid access for the educated user to the capabilities of the model. • Short runtime. Because Advisor is a backwards looking model it runs between 2.6 and 8.0 times faster in standard drive cycles than forward looking models ( Wipke, 1999). Weaknesses: 31 • Documentation helps only very little if the model needs to be modified. • The reverse causality makes it difficult to follow the logic of the model. This is one major obstacle for future improvement and development. • Interaction between fuel cell stack, fuel processor and drive train does not include feedback effects. For example it is assumed that the fuel processor is always able to deliver the by the stack required reformate in time. The effect of a drop in stack voltage because of a supply shortage of reformate gas is not modeled, and consequently the electric motor would not provide less torque because of the voltage drop. The feedback of the various components is essential for the modeling of one major issue of fuel cell system and vehicle analysis  transient behavior. The model allows one to investigate only in a very limited way the impacts of different component configurations, parameter variations and control strategies on transient behavior. • If one component is not able to supply the value required by the previous stage, the operating point of the requesting component is not corrected. If component characteristics vary largely over the operating regime, then ignoring the change of the operating point could impose a large error on the results. An iteration process downstream of the limiting component could potentially solve this problem. However this would significantly complicate the model and is not realized in the current version of Advisor. 32 2.2.4. The UC Davis Hydrogen ( 1998 Version) Model The original direct hydrogen fuel cell vehicle model of University of California, Davis ( UC Davis) was programmed during 1998. It is part of a modeling effort sponsored by a group of industry and public sponsors and is not publicly available. It is essentially based on a previous version of Advisor and follows therefore the same structure of a backwards facing model ( Figure 2 7). From a practical point of view the complications are the same as with the Advisor model and are mainly a direct result of the reverse causality. The program employs also an extensive graphical user interface easing the simulation of the different vehicle configurations ( Figure 2 8). The model is specialized for direct hydrogen fuel cell vehicles in a load following and load leveling configuration. In addition pure battery electric vehicles could be modeled. Similarly to Advisor, the fuel cell system is modeled in non transient form employing steady state polarity plots characterizing the fuel cell stack ( fuel cell system place holder model). In addition to the actual fuel cell model, algorithms have been developed that optimize the interaction between various compressor technologies and the fuel cell stack. The results of this optimization process are then included into the vehicle model. However the combination of fuel cell stack and air supply with the optimization strategy makes it difficult to gain the necessary input data in a laboratory for a specific stack or compressor supplier. A new forward looking direct hydrogen fuel cell vehicle model has succeeded this program in 2000. 33 Strengths: • Short runtime similar to Advisor, • Graphical user interface including features for the automatic report generation. • Attempt for the integration of an optimal compressor operating strategy. The direct hydrogen model of UC Davis is the only model ( discussed in this overview) addressing and discussing the potential energy savings in this area. Weaknesses ( see Advisor): • Reverse causality makes it difficult to follow the logic of the model and is one obstacle for further improvement and development, • No feedback effects between motor and fuel cell system interaction modeled, • No correction of the operating point if one component is unable to meet the request, • Separate program required for the integration of new fuel cell stacks and compressors or the modification of the compressor control strategy (“ config” model). 34 Figure 2 7: UC Davis Hydrogen Fuel Cell Hybrid Vehicle Model m/ sec trip transmission stop simulation at specific SOC road load motor/ controller energy storage clock actual velocity mph Simulation Results SOC last Fuel Cell System 35 Figure 2 8: Graphical User Interface of the Hydrogen Fuel Cell Hybrid Vehicle Model of UC Davis 36 2.2.5. The Simplev ( Simple Electric Vehicle Simulation) Model Idaho National Engineering and Environmental Laboratories ( INEEL) developed Simplev beginning in 1990. Since then several updates have been released. The latest update is Simplev 3.0. However the simulation package has been phased out in 1997. It is programmed applying a backwards method ( Idaho National Engineering and Environmental Laboratory, 1993). This programming approach is physically and mathematically less solid than the forward looking approach15. Simplev does not support the method of co simulation. Because Simplev is programmed in Basic, and the source code had not been made available, it is not possible for the user to expand and modify the initial program package. Because of the reverse causality Simplev does not support rapid prototyping. The required input data are standard vehicle and component parameter and steady state maps for motor efficiency, transmission efficiency etc. All the input data are either available or could be made available using standard methods, such as battery and motor bench tests. The program assists the user with a simple graphical interface. The runtime is very short compared with the other program packages. Simplev is capable of simulating various types of internal combustion engine hybrid and battery electric vehicles. Simplev, in its original form, is not able to simulate fuel cell vehicle concepts. It should be noticed that Simplev was introduced in 1990, and was among the first comprehensive programs modeling vehicles employing electric drive trains. Simplev was phased out by INEEL in 1997. 15 See appendix 37 Strengths: • Runtime Weaknesses: • Backwards approach, • No fuel cell vehicle modeling capabilities, • The electric drive train is not sensitive to voltage, • Not flexible ( Source code not available), • No documentation for version 3.0, • No longer available. 38 2.3. Summary Several vehicle modeling tools have been introduced and compared with each other. The points of comparison have been a list of generic requirements for mathematical modeling stated at the beginning of the chapter and restated in the first seven items in Table 2 5. These criteria define the theoretical potential of the modeling approach. In addition in the second half of Table 2 5 ( items 8 10) the actual realized potential has been compared among the different models. Finally the last row states the public availability in October 2000. The compared models could be classified in two different groups. Hyzem and Psat as forward looking models and Advisor, UC Davis H2 ( 1998 version) and Simplev in the group of backwards looking models. The items 1 5 in Table 2 5 state the theoretical potential of the models to incorporate future developments in an efficient and time saving manner. It can be seen that in this respect the group of causal forward looking models offers a higher potential than the group of non causal backwards looking models. The item Nr. 6 “ ease of use” includes two different aspects. First, the support the user receives through a graphical user interface and a good documentation, and second, the logical structure of the model and how it supports modifications. Table 2 5 shows that none of the models have an advantage regarding the ease of use. However this represents only the current state. Hyzem is valued neutral because it does not support the user with a graphical user interface but has a causal structure easing understanding and modifications. Advisor, UC Davis H2 ( 1998 version) and Simplev are valued neutral because they employ a graphical user interface and a non causal structure. Psat is valued 39 neutral although it offers a graphical user interface and a forward looking structure. The reason is that version 4.0 was still in the development state and the user interface was little flexible and unstable. Because a graphical user interface could easily be added to the causal models, while changing the non causal structure of the backwards looking models is not possible the theoretical potential for a better “ ease of use” for the causal models is estimated to be higher. The availability of input data ( item 7), though important, is not a feature that distinguishes the models. Only the UC Davis Hydrogen model ( 1998 version) has a ( minor) disadvantage in this area because of the combination of stack and air compressor data. 16 Items 8 10 compare more specifically how much of the theoretical potential of each model has actually been realized in the current versions. Again the models could be separated into the causal and non causal types. Item 8 shows the vehicle concepts realized today. The differences shown should not be over interpreted. In principle all vehicle types could be modeled with each model. Most of the differences shown could be explained based on the history of the individual models and their sources of funding, primary objective, etc. However the fact that Advisor does not include an indirect methanol fuel cell vehicle model could be one hint towards the difficulties of incorporating non instantaneous responding systems, such as a methanol steam reformer, into the model. Item 9 compares the possibilities of incorporating dynamic characteristics in each model, on hand of the example of start up issues and fuel processor time constants. 40 Though the incorporation of these features is in principle possible in all models, the required effort for the case of non causal models is much larger. Consequently none of the mentioned features has been realized in this vehicle group. The causal models have a significant advantage over the non causal models. The reason is that the causal structure allows the incorporation of dynamic characteristics without difficulties if the physics of the system are understood. Item 10, the issue of emissions, is not an area in which the models are fundamentally different. All models are in principle able to model emissions. However for models only considering hydrogen as a fuel ( UC Davis, H2) the task of modeling emissions is irrelevant. The applied method of modeling emissions in today’s program versions is quasi static with tables including the emissions depending on the emitters ( anode gas burner, fuel processor) operating point. Finally item 10 compares the availability of the individual models in October 2000. At this time only Advisor was publicly available ( as free download on the Internet). However the Southwest Research Institute and Argonne announced that the PSAT model would be made available at a later time this year. Since October 2000 a beta version of PSAT is already available for researchers in the field of fuel cell vehicle modeling only. From a fundamental point of view none of the above models are satisfying. The investigated models compromise in a number of different areas, such as separation of control algorithms from component models and causality. As a result the models become difficult to understand, non modular ( even if they appear modular on the surface) and difficult to validate. 16 This comparison only considers the vehicle level. However in addition to the UC Davis H2 vehicle model a second model is existing generating the necessary vehicle model input data from standard data 41 Also, because of the number of compromises made, none of the investigated models appears suitable as a teaching instrument in companies or universities. Although this aspect is secondary for a professional use in industry, or in the policy arena, it seems important that long term suitable tools for teaching in the area of fuel cell vehicles are available. Based on this comparison a new fuel cell vehicle model is proposed. Key characteristics of this new model are: • Emphasis on fuel cell vehicles, • Incorporation of hybrid concepts including ultra capacitors, • Causal structure, • Preparation of rapid prototyping, • Incorporation of dynamics aspects, • Modular topology, • Incorporation of the new indirect methanol and indirect hydrocarbon fuel cell system models of UC Davis ( Eggert, 2000, Fuel Cell Modeling Group, 2000), • Incorporation of the new direct hydrogen fuel cell system model ( Cunningham, 2000), • Logical structure. such as compressor maps and stack properties ( config model). 42 Model Requirement HY ZEM PSAT Advisor UC Davis H2 Simplev 1. Theoretical soundness + +    2. Completeness + O O O O 3. Flexibility + O    4. Expanded resolution through cosimulation + + O   5. Validation supported through rapid prototyping + ( current version)  ( 1996 version)     6. Ease of use O O O O O 7. Input Data Available + + +  + 8. Realized fuel cell vehicle models ( 2000) Indirect  Methanol and direct H2 in hybrid and non hybrid Versions, no ultra capacitor designs Only battery hybrid fuel cell Vehicles, no ultra capacitor designs Indirect Gasoline and direct H2 in hybrid and non hybrid versions, no ultra capacitor designs Direct H2 in hybrid and non  hybrid versions, no ultra capacitor designs  9. Dynamic Considerations ( Start up, reformer time constants) + current version  Place holder model  Place holder model  Place holder model  10. Modeling of Emissions + ( maps) +( maps)  Not applicable + ( maps) 11. Availability ( October 2000)  +( free17) + ( free)   Table 2 5: Benchmark ( negative or not possible, O neutral, + good). Not emphasized are: 17 For registered researchers. 43 • The employment of a graphical user interface, • Large component libraries, It is expected that through these key features a new fuel cell vehicle model could be developed with applications in • Academia and government ( in teaching and as a tool for policy analysis), • The vehicle industry ( for the analysis of different concepts), • The component industry ( for product planning and technology comparisons). 44 3. Applied Modeling Methodology 3.1. General Aspects For a realistic and defendable vehicle model, only a physically and mathematically well defined and documented modeling approach is acceptable. Therefore this dissertation work chose a causal forward looking18 modeling approach. For modeling of the control algorithms, an approach emphasizing the strict distinction between the controlled system and the controller controlling the system is proposed. For the modeling of the components, either an approach based on first principles or an approach based on experimental data has been applied. Examples for the first principle approach are the modeling of the mechanical properties of the vehicle ( inertia, friction, rotational inertia) or the modeling of the fuel cell stack. Examples for modeling based on experimental data are the use of efficiency maps for the electric motor and transmission. The decision of which approach to follow depends on: • The availability of experimental data; • The complexity a first principle component model would add to the overall model and the effects on run time ( practicality); • The purpose of the model, e. g. what is the question asked. If the emphasis is towards aggregate vehicle properties, individual component models could eventually be simplified. If the emphasis is on one specific component, modeling 18 See literature review ( Hauer 2000). 45 in greater detail than in the first case might be necessary. Two methods to accomplish this are possible: First, by programming a more complex SIMULINK model, and second by employing a special programming tool for a specific component or characteristic. SIMULINK and the other, specialized, program, e. g. SABER for electric components, would then work together. This method is called co simulation. Although not applied in this work, the modular, forward looking structure of the model supports the method of co simulation. Because of the modular structure of the model, the modeling of each component is not limited to either the choice of a first principle model or an approach based on experimental data. Component models are exchangeable as long as the interfaces are compatible. Therefore the results of a detailed component model could be compared with a simpler one running both in the same overall vehicle model. If the differences between both models are neglect able and the focus of interest is on the vehicle and not the component itself one might decide to use the simpler component model for the benefit of a faster runtime. In addition to the above mentioned method of co simulation, the model structure supports the use of rapid prototyping. In this context, rapid prototyping means the process of developing control algorithms in the software model, which are later transferred into existing hardware. The model supports also the concept of “ hardware in the loop,” allowing the replacement of component descriptions of the software model with hardware. From a modeling point of view, “ rapid prototyping” and “ hardware in the loop,” techniques offer the chance for faster model validation. 46 3.2. Mathematics 3.2.1. Introduction The modeling, based on first principles, is done by applying a standard input/ output approach as described by Leonhard ( Leonhard 1985) and Foellinger ( Foellinger 1985) for time invariant systems with one or multiple inputs x( t) and one or multiple outputs y( t). Mathematical component and hardware descriptions are formulated in the form of ordinary differential equations with the time t as the independent variable. The system description could be given in the form of one or several ordinary differential equations dy/ dt = f( t, x( t), y( t)) for the output function y( t) ( Figure 3 1). Figure 3 1: Time invariant input output system for one input x( t) and one output y( t) and a 1st order differential equation relating output and input function. The input function x( t) could be of any form, including discontinuous functions, e. g. a step function or a pulse. The only limitation is that x( t) has to be defined for the complete time interval of interest [ 0, t]. The output function y( t) is calculated as a function of the input function x( t) applying the system description dy/ dt = f( t, x( t), y( t)). For a physical system no singularities are expected. Therefore y( t) is defined for the whole time interval [ 0, t]. The differential equations describing the system could be either of linear or nonlinear form. The equations describing the system are not limited to first order equations. f( t, x( t), y( t)) dt dy = x( t) y( t) 47 A system description with higher order differential equations is possible. In case that the component model requires a higher order differential equation, e. g. nth order, it can be transformed into a first order system of n differential equations that could be solved easily in SIMULINK ( Mathworks corporation, 2001). The general approach for the transformation of an nth order equation is to substitute the higher order derivatives by introducing new variables. Equation 3 1 shows a nth order differential equation with the input function x( t) and the output function y( t). x( t) system input y( t) system output independent time variable : ( ) , ( ), ( ), ( ) ,..., ( ) , ( ) 1 ( 1) 2 ( ) ( 2) = = = = − − − − t where dt d y t dt d y t dt f t x t y t dy t dt d y t n n n n n n Equation 3 1 To solve Equation 3 1 in SIMULINK, it has to be rewritten into a system of n 1st order differential equations for the n unknown functions y( x, t), y1( x, t) .. yn 1( x, t) ( Equation 3 2). 48 dt y t dy t y t dt y t d y t dt y t d where y t dt dy t y t dt dy t y t dt dy t y t dt dy t g t x t y t y t y t dt dy t n n n n n n n n n ( ) ( ) ... ( ) ( ) ( ) ( ) : ( ) ( ) ( ) ( ) ... ( ) ( ) ( ) ( ) ( ) ( , ( ), ( ), ( ),..., ( )) 1 2 2 2 1 1 1 1 2 1 2 3 1 2 1 2 1 1 = = = = = = = = − − − − − − − − − Equation 3 2 The resulting system in Equation 3 2 can be directly programmed in SIMULINK. Essentially SIMULINK provides the solution not only for the function of interest y( t) but also for the first n 1 derivatives of y, respectively y1 … yn 1. The algorithm to rewrite the n th order differential equation does not require linearity in the original equation. It can also applied if the original equation is of nonlinear form. The order of the system is also not a constraint, although physical systems are seldom of a higher order than two. If the system has more than one input x( t), all inputs have to be considered. The first equation in Equation 3 2 is then a function of all inputs x1, x2 … xm, if m is the number of input variables. 49 If the system has more than one output function y( t), the above method can be applied for each output function. An example of a multi input/ output system is the air supply system in which pressure and flow rate set points are input variables and the actual pressure and flow rates in the stack form the output variables. Start of the simulation ( Initial values): For the numerical solution, initial conditions for the integration of the system have to be considered. For a system of nth order, n initial conditions are required. Initial conditions are the values of y1( t= 0),…, yn( t= 0). They are incorporated in the form of initial values of the integrator blocks in the SIMULINK diagram. The so derived first order system of differential equations could then be solved in SIMULINK. An example of a solution to a 2nd order system in SIMULINK with one input and one output is provided at the end of the chapter. Discontinuities: A discontinuity in this context means that the derivative from the left side is different from the derivative from the right side in ( at least) one point of a function. The function is then discontinuous in this point. An example would be if there is a kink in the function. Discontinuities are common in the control algorithms applied for controlling the various components. They are introduced in the form of saturation blocks, switches, thresholds, and tables, and are necessary to model the applied control algorithm. 50 SIMULINK offers a vast number of functions to ease the incorporation of discontinuities into the model. In an analytical approach, the presence of discontinuities makes it harder to solve the equation because it has to be solved for each continuous interval separately. For the numerical approach applied in this work, the problem of discontinuities is less challenging. The applied method for solving the system is to work with one set of differential equations until the solution reaches a discontinuity. The simulation stops and continues then with a new ( modified) set of equations, taking the old system’s last vector of output values as vector for the initial values for the new system. After this, the simulation proceeds as usual until the next discontinuity arises. Not considered in this model are time discontinuities. Realistically, due to the fact that most of the control algorithms are programmed in the software and run in discrete time steps in microprocessors, all control algorithms have to be modeled in discrete form. However, due to the high processor clock speed in comparison to the system time constants, the impact of time discontinuities is minimal and could be neglected. If the processor clock speed is in the order of magnitude of the inverse of the smallest time constant within the controlled system model, the control algorithm would have to be modeled in a time discrete form ( Leonhard 1990). Applied solving algorithm for solving differential equations: SIMULINK offers several solvers supporting the numerical integration of ordinary differential equations. The solvers provided could be classified as variable step solvers and fixed step solvers. 51 Fixed step solvers do not vary the simulation step size during the simulation. Therefore the step size has to be small enough to capture the most transient intervals of the solution with sufficient enough accuracy. On the other hand, a too small step size slows the simulation down. For the hybrid vehicles modeled in this work, the recommended method is the Euler method ( ODE 1). The use of this algorithm for hybrid cases shortens the execution time significantly. Alternative fixed step solvers, available in SIMULINK, are listed in Table 3 1. Variable step solvers vary the step size depending on the slope of the solution. In intervals with a small slope, the step size is increased, while in areas with steep slope ( rapid change of the solution), the step size is decreased to minimize the computational error. The motivation of the variation in step size is to increase the speed of the simulation. Variable solvers provided by SIMULINK are listed in Table 3 1. Among the variable step solvers the ODE 45 method provides a good compromise between reliability ( how likely is it that the simulation runs to the end) and efficiency ( how fast does the simulation run) for the models discussed in this dissertation. The standard solver applied in this work is the Euler algorithm ( Bronstein 1985) for solving the system of differential equations that form the overall model. Assuming the system that has to be solved is stated in explicit form ( Equation 3 3) with the input function x( t) and the output function y( t) ( Figure 3 1): ( ) f ( x( t), y( t)) dt dy t = Equation 3 3 Applying the standard differentiation formula leads to ( Equation 3 4). 52 step size : ( ) ( ) ( ) ( ( ), ( )) Δ = = Δ = + Δ − t where f x t y t t y t t y t dt dy t Equation 3 4 Solving for y( t+ Δt) results in: y( t + Δt) = y( t) + Δt ⋅ f ( x( t), y( t)) Equation 3 5 The recursive algorithm in Equation 3 5 is named the Euler formula. Starting with an initial value y( t= 0), Equation 3 5 allows the integration of the differential equation stated in Equation 3 3. The step size Δt stays constant in this algorithm. In some cases, especially if the solution has large intervals [ t1, t2] with only little variation, the adjustment of the step size could decrease the overall runtime. In intervals with little variation, the step size is increased, while in areas with large variation ( or high dynamic), the step size is decreased. SIMULINK provides assistance for varying the step size offering variable time step solvers. Essentially, the absolute tolerance ε between two steps and the relative tolerance λ between two steps is calculated. If one or the other exceeds a ( in the user interface adjustable) parameter, the iteration step is repeated with a smaller time step size Δt ( Equation 3 6). For checking the relative step size at locations y( t) close to zero a special “ zero crossing feature” could be activated to avoid difficulties in determining the step size in these situations ( Simulink 2001). 53 relative tolerance absolute tolerance : ( ) ( ) ( ) or ( ) ( ) = = + Δ − ≥ + Δ − ≥ λ where decrease Δt and repeat step then y t if y t t y t y t t y t ε ε λ Equation 3 6 Table 3 1: Fixed and variable time step solvers. Fixed step size solvers Description ode1 ( Euler algorithm) This method provides an efficient and reliable solution for all hybrid cases. The recommended step size is 0.005 sec. Recommended solver for all the models used in this dissertation. ode5, ode4, ode3, ode2 For a detailed description see the Simulink web page ( Simulink 2001). None of the listed solvers could ( significantly) increase the reliability or runtime of the simulation. Variable step size solvers ode45 Based on an explicit Runge Kutta ( 4,5) formula, in general, ode45 is the best solver to apply as a " first try" for most problems. ode23, ode113, ode15s, ode23s, ode23t, ode23tb For a detailed description see the Simulink webpage ( Simulink 2001). Depending on the exact configuration of the model one of the listed solvers might lead to a ( i) more reliable, ( ii) more efficient solution. 54 Runtime: Two different effects determine the run time of the overall vehicle model: • The complexity of the model ( this is the number of blocks forming the model); • The system dynamics ( this is how fast the solution including intermediate values change over time). It appears obvious that the runtime increases with the system complexity. More blocks add essentially more equations to the overall system and more equations means that for every iteration step more computations have to be performed. For fixed computational resources, the runtime increases with increasing complexity. Not so obvious is that the system dynamics can have a much stronger effect on runtime than the increase in complexity has. If a system is highly dynamic ( e. g. if parts of the system are oscillating), in the interval of interest or shows rapid state changes only at certain times the runtime could increase significantly. In either case the reason for the increased runtime is that the simulation step size has to be small enough to capture all transient effects. If the solution shows highly transient behavior only at certain points in time ( e. g. during an acceleration), a variable step solver could reduce the runtime. However, if the solution is transient over the complete interval of interest ( e. g. oscillating), the step size has to be kept small all the time. For this case the number of calculations and therefore the runtime increases independent from the choice of the solver. For the sake of a reasonable runtime and due to the finite computer power ( floating point operations / second), the modeling has be constraint to the dominant time constants within the system. 55 A mixture of large and small time constants with a ratio of largest to smallest time constant of several orders of magnitude slows the simulation significantly down. The smallest time constant is effectively determining the step size and with this the total run time of the simulation. For example, the consideration of the cable inductivity and capacity between the fuel cell system and the electric drive train of a vehicle should be avoided because this time constant is significantly smaller than the mechanical time constants due to rotational inertia of the electric drive train or the vehicle mass. On the other hand, in feedback systems it can be necessary to consider even secondary ( small) time constants to avoid algebraic loops in the modeling process. The presence of algebraic loops in the simulation model can be interpreted as an indicator that the analysis of the system is not detailed enough. A significant aspect of the system has not been captured in the model. 19 In case of the presence of an algebraic loop how an additional time constant could be introduced into the system must be carefully analyzed. For the case that no algebraic loop is present, one must consider if the introduction of additional ( smaller) time constants is necessary to describe the interesting properties of a system or if this just leads to an increase in run time. However, in this model it appears that considering the system determining time constants leads to a system model without any algebraic loops, which captures all dominant effects. 19 This is true for physical systems. It can be said that in nature no algebraic loops exist ( no immediate feedback from a system output to a system input). 56 3.2.2. Example and Transfer into SIMULINK Equation 3 7 describes the horizontal movement of a vehicle with the mass m considering an aerodynamic drag, wheel inertia, tire friction, and an external acceleration Force F ( Gillespie 1992). ( ) ( ) ( ) 0 2 ( ) ( ) ( ) 1 2 2 2 2 2 2 1 2 3 2 + Θ ⋅ − = + ⋅ ⋅ ⋅ ⋅ ⋅ + + ⋅ + ⋅ F t dt d s t dt r cw A ds t dt ds t dt ds t dt m d s t μ μ μ ρ Equation 3 7 Following the conclusions of the previous chapter the above 2nd order nonlinear differential equation can be rewritten into a system of two 1st order differential equations by the method of substitution ( Equation 3 8). ( ) ( ) ( ) 2 ( ) ( ) ( ) 0 ( ) ( ) ( ) 1 2 2 2 1 2 3 v t dt ds t F t dt dv t r v t v t cw A v t dt m dv t = ⋅ + μ + μ ⋅ + μ ⋅ + ⋅ ⋅ ρ ⋅ ⋅ + Θ ⋅ − = Equation 3 8 Rearranging Equation 3 8 results in: [( ) ] ( ) ( ) 2 ( ) ( ) 1 ( ) ( ) 2 ( ) 1 2 1 2 3 2 v t dt ds t F t v t v t cw A v t dt m dv t r = ⋅ − + ⋅ + ⋅ + ⋅ ⋅ ⋅ ⋅ + = Θ μ μ μ ρ Equation 3 9 In Equation 3 9 s( t) has the meaning of the distance traveled from t= 0 until t and v( t) is the vehicle velocity at the time t. Because the system of differential equations has two unknown functions v( t) and s( t), two initial conditions have to be considered. These are the vehicle velocity at the beginning of the experiment ( or simulation) v( t= 0) = v0 and 57 the location of the vehicle at the beginning of the experiment s( t= 0)= s0. Equation 3 9 can be seen as the description for an input / output system. System input is the acceleration force F( t) and system outputs are the vehicle velocity v( t) and the vehicle location s( t). Together with the above mentioned starting conditions, the system can be easily solved in SIMULINK for all input traces F( t). Figure 3 2 shows the graphical representation of the SIMULINK algorithm. ∫ 2 1 r m+ Θ 2 ⋅ cw ⋅ ρ ⋅ A 1 F( t) ∫ v( t) s( t) x2 x2  +    μ1 μ2 μ3 Figure 3 2: Graphical representation of Equation 3 9. The initial conditions s( t= 0)= s0 and v( t= 0)= v0 are equivalent to the integrator status at t= 0. Therefore the initial conditions can be directly programmed into the SIMULINK representation. 58 4. Model Description 4.1. Modeling Structure and Goals This chapter explains the setup of the fuel cell vehicle model. The model is developed using a forward looking approach ( Hauer 2000). The model description starts with the most upper level, the vehicle. This level illustrates how the driver is interacting with the vehicle and how the drive cycle is fed into the model. After the establishment of this overall modeling frame, the models for all major components are explained in the chapter “ Component models.” The component models interface with each other and form, together with the vehicle properties, the overall vehicle model. One individual component could also consist of several subcomponents. One important characteristic of this model is that the component interfaces transfer only physical properties from one component to the other components. The limitation to “ physical“ interfaces qualifies the model for the use in rapid prototyping experiments. It also benefits the understanding and eases maintenance and further development because the model could be more easily associated with an image of the physical reality of the vehicle. Because of the strict modularity, individual component models could be tested off line or replaced with a different model for the same component if the interfaces of the replacement model match the interfaces of the model replaced. Besides the component models, the control strategies for the interaction of the individual components determine the overall vehicle characteristics. These control strategies are also explained under the headline “ Component models.” An example for a control strategy in a non hybrid vehicle is the control algorithm for the fuel processor. An example for a control strategy in a battery hybrid vehicle is the activation of the fuel cell 59 system depending on the motor power and/ or the state of charge of the battery and/ or other parameters. The modeling effort pursues two objectives: First to estimate fuel consumption, energy flows and losses, and the vehicle dynamics ( acceleration time and top speed) for different vehicle configurations ( parameters) and different vehicle types ( hybrid, non hybrid vehicles). Second the safe and fast investigation and development of control strategies for the exploration of theoretical limits and the use in existing hardware later. 60 4.2. Vehicle Model The uppermost level of the fuel cell vehicle model consists of the main blocks “ Specified Drive Cycle”, “ Driver” and “ Vehicle" ( Figure 4 1). Figure 4 1: Uppermost level of the indirect methanol fuel cell vehicle model. Driver Vehicle Specified Drive Cycle Vehicle velocity Brake pedal position Acceleration pedal position 61 4.2.1. Drive Cycles and Driver Model This chapter discusses the drive cycles available in the model and the algorithm that compares these drive cycles with the actual vehicle velocity and adjusts the acceleration and brake pedal position. The block “ Specified Drive Cycle” describes the demanded driving profile by specifying the velocity over the time. Standard drive cycles available in this simulation tool are the drive cycles listed in Table 4 1. Available Drive Cycles Length / Time Max. speed / Avg. speed Max. accel. Avg. accel. Federal Urban Driving Schedule ( FUDS) 7.45 mi / 1369 sec 56.7 mi/ h / 19.6 mi/ h 1.48 m/ sec2 0.34 m/ sec2 Federal Highway Cycle 10.26 mi / 765 sec 59.9 mi/ h / 49.2 mi/ h 1.43 m/ sec2 0.13 m/ sec2 US O6 Cycle 8.01 mi / 600 sec 80.3 mi/ h 48 mi/ h 3.75 m/ sec2 0.45 m/ sec2 ECE Cycle 0.62 mi / 195 sec 31.1 mi/ h 11.4 mi/ h 1.05 m/ sec2 0.43 m/ sec2 MVEG Cycle 6.79 / 1220 sec 74.6 mi/ h 20.03 mi/ h 1.05 m/ sec2 0.37 m/ sec2 EUDC 90 6.58 mi / 1220 sec 55.9 mi/ h 19.4 mi/ h 1.05 m/ sec2 0.39 m/ sec2 EUDC 120 4.32 mi / 400 sec 74.6 mi/ h 38.9 mi/ h 0.83 m/ sec2 0.26 m/ sec2 Japanese 10 15 cycle 2.59 mi 660 sec 43.5 mi/ h 14.1 mi/ h 0.79 m/ sec2 0.39 m/ sec2 Table 4 1: Available standard driving cycles with their main characteristics. The block “ driver” represents the driver properties and driver characteristics. The main task is the comparison of the velocity specified in the driving cycle with the actual vehicle velocity. In case the actual vehicle velocity is below the vehicle velocity specified in the drive cycle the driver sends an acceleration command to the vehicle block. In case the vehicle velocity is above the specified velocity the driver sends a brake command to 62 the vehicle block. In a real vehicle, the acceleration signal and the brake signal represent the position of the acceleration pedal and brake pedal. From a systems point of view the driver can be seen as a controller for the “ system” vehicle. The inputs for the “ system” vehicle are the acceleration and brake commands and the system output is the vehicle velocity. Although the presence of a driver model is important for the setup of the simulation, this analysis will not focus on the block " driver." The only criteria this block has to meet is to ensure that the vehicle follows the drive cycle as closely as possible whenever physically possible. In this respect the block " driver" has the same task as a driver on an emissions bench, namely following a given drive cycle. The complete driver model is shown in Figure 4 2. Drive cycle Td  + Ti  + Tr >= 0 <= 0 proportional integral predicting the future delay vehicle velocity k1 k3 1/ Ti + + + reaction time acceleration request brake request y1 y2 y3 y4 Figure 4 2: Driver model. The model inputs are the specified drive cycle and the vehicle velocity. The model outputs are the normalized ( between 0 and 1) acceleration request and the normalized ( between 0 and – 1) brake request. The following steps are taken to calculate the output values in dependence of the input values. The ( actual) vehicle velocity is subtracted from the ( delayed) drive cycle 63 request. The difference between both values is fed into a proportional integral controller ( PI controller). The proportional part is calculated according to Equation 4 1. ( ) time [ sec] time is the time the driver looks into the future [ sec] drive cycle velocity [ km/ h] vehicle velocity [ km/ h] proportion al factor of the PI algorithm [ 1/ km h ] : y ( ) ( ) ( )  1 1 1 1 = = = = = ⋅ = ⋅ − − t T v ( t) v( t) k where t k v t v t T d cycle cycle d Equation 4 1 The integral part of this PI controller is realized using an integral algorithm with a build in anti windup feature ( Figure 4 3). The reason is to avoid the windup of the integrator to very high values in cases the vehicle is physically not able to meet the drive cycle, e. g. in an acceleration experiment). Equation 4 2 describes the algorithm of the integrator with anti windup function. y ( ) output of the integrator with anti  windup [ 1] y ( ) intermediate value [ 1] c feedback constant [ km/ h] integration constant [ h/ km] : ( ) 1 ( ) ( ) ( ( )) 2 2 1 0 2 1 2 2 = ′ = = = ⋅ ′ = ⋅ − − + ⋅ − ′ ∫ t t T where v t v t T c y y t dt T y t i t cycle d i Equation 4 2 The final output of the integrator with anti windup is stated in Equation 4 3. upper and lower bound for y [ 1] : ( ) if ( ) ( ) ( ) if ( ) 2 2 2 2 2 2 2 2 2 2 = = ′ ≥ = ′ ′ < y where y t y y t y y t y t y t y Equation 4 3 64 Ti ++  + input ideal integrator limiter c1 y2’ y2 Figure 4 3: Integrator with “ anti windup function”. In addition to the PI algorithm, a third component impacting the driver request can be added ( Equation 4 4). This third component takes into account that on an actual roller test stand the driver is able to foresee the future drive cycle. 20 This knowledge about the future can improve the driver’s decision and allows a more accurate following of the drive cycle. The value the driver pays to the future is taken into account by a gain block. A gain of zero would mean that the driver does not pay any attention to the future at all. With increasing gain his attention increases. The delay determines how far the driver looks into the future. A delay of zero would be equivalent to a time horizon of zero seconds. If the delay time increases, the driver’s time horizon increases. 20 In a roller test stand the drive cycle request is communicated on a screen. This screen does not only show the current velocity request in digital form. Instead, the drive cycle, including the next few seconds of the drive cycle together with the actual vehicle speed, is displayed in the form of speed traces. Therefore, the driver is able to take the future velocity requests into account and base his current decisions on this additional knowledge. The net effect is that the driver can follow the drive cycle more accurately. 65 ( ) ( ) intermediate value [ 1] constant for how the driver values the future [ h/ km] : ( ) ( ) ( ) 3 3 3 3 = = = ⋅ − − y t k where y t k v t v t T cycle cycle d Equation 4 4 All three intermediate values y1, y2, and y3 are summed and filtered through a low pass filter in the form of a first order transfer function ( Equation 4 5). y ( ) intermediate value [ 1] filter time constant [ sec] : ( ) ( ) ( ) ( ) ( ) 4 4 1 2 3 4 = = ⋅ + = + + t T where y t y t y t y t dt T dy t r r Equation 4 5 Finally, the filtered value is limited to values between  1 and 1, which are then interpreted as the driver’s request for more or less acceleration. According to Equation 4 6, positive values are interpreted as a request for acceleration. Negative values are interpreted as a request for deceleration ( braking). brake_ request driver request for deceleration ( braking) [ 1] acc_ request driver request for acceleration [ 1] where : 0 if y ( t) 0 1 if y ( t)  1 if  1 y ( t) 0 0 if y ( t) 0 1 if y ( t) 1 if 0 y ( t) 1 4 4 4 4 4 4 4 4 = = = > = − < = ≤ ≤ = < = > = ≤ ≤ brake_ request brake_ request brake_ request y ( t) acc_ request acc_ request acc_ request y ( t) Equation 4 6 66 4.2.2. Physical Vehicle Model In the previous chapter, the driver model and how the driver controls the actual vehicle velocity were discussed. In this chapter, the model for the vehicle and its main components and component arrangements will be explained. The block “ vehicle” in Figure 4 4 contains the four sub blocks “ Drive Train,” “ Vehicle Curb,” “ Power Source,” and “ Vehicle Controls” ( Figure 4 4). The inputs of this block are the brake pedal position and the acceleration pedal position. Both are derived in the previous chapter. The model output is the actual vehicle velocity. The acceleration pedal position feeds into the block " Drive Train" and determines the fraction of the maximum motor torque available supplied to the vehicle wheels. The brake pedal position feeds into the block “ Vehicle Controls.” This block separates regenerative braking ( in hybrid vehicles only) and mechanical braking. The request for regenerative braking is fed to the block “ Electric Motor” and the request for mechanical braking is fed directly to the block “ Vehicle Curb.” Drive Train Vehicle Curb Power Source current torque motor speed voltage acc. pedal position brake pedal position Vehicle Controls velocity Figure 4 4: Content of the block " Vehicle". 67 The block “ Drive Train” includes models for the power electronics for the electric motor, the electric motor itself, controls for the electric motor, and the transmission. Depending on the driver request, expressed by the acceleration pedal position and brake pedal position, the block “ Drive Train” provides torque to the wheels and draws current from the power source ( battery, ultra capacitor, or fuel cell stack). The block “ Vehicle Curb” models the mechanical properties of the vehicle curb such as aerodynamic drag, rolling resistance, mass, etc.. The inputs into this block are the applied wheel torque and the signal for the mechanical brake fraction. The outputs are the vehicle velocity and the motor speed. In designs not considering tire slip and a one speed transmission, both values are directly correlated with each other. The block “ Power Source” could include models for a fuel cell system, a battery system, an ultra capacitor system, or a combination of all three systems. The input of this block is the electric current drawn by the motor. The output is the voltage seen by the dc terminals of the power electronics for the electric motor. For the case of a non hybrid fuel cell vehicle this is the same voltage as the fuel cell stack voltage. In hybrid designs, this voltage could be the battery voltage or any other voltage depending on the exact design. The overall design of the vehicle model incorporates two major feedback loops motivated by the dependence of the maximum motor torque of the electric drive train on the voltage supply and the motor speed. As soon as the driver signals a torque request the electric drive train starts providing torque to the wheels. Because of this torque supply, the vehicle accelerates and the motor speed increases. This increase in motor speed feeds back to the block “ Drive Train” because of the sensitivity of the motor torque to 68 fluctuations of motor speed. This feedback loop represents the feedback on the mechanical side of the vehicle. As soon as the motor starts spinning, it provides mechanical power to the wheels. It can only do this by drawing electrical power from the block “ Power Source.” As a result, the motor draws an electric current from the power source. Due to the internal resistance21 of the power source, the voltage at the motor terminals drops depending on the load current drawn. Because of the sensitivity of the maximum motor torque on the supply voltage, the drop in voltage feeds back to the electric drive train. This feedback loop represents the feedback effects on the electrical side. Mechanical and electrical feedback together determine the overall characteristics of the combined system drive train, power source, and vehicle curb, which form the overall vehicle model. This setup of the vehicle is close to the setup of a physical vehicle. The only interface22 between the drive train and the source of electric power is the electric connection between both components. This interface can be fully described by change of voltage and current over time. On the mechanical side, the interfacing variables between the drive train and the vehicle curb are the wheel torque and the wheel speed. Similar to the electric side, the interface can be fully described by providing both values in time. Properties of the vehicle and the vehicle environment The overall vehicle is modeled according to the force balance stated in Equation 4 7. This equation accounts for the aerodynamic drag force; the friction force due to the rolling resistance of the tires; the vehicle inertia including rotational inertia of tires, motor, and transmission; and the climbing force necessary to climb a hill. The sum of all 21 The internal resistance could vary over time. 69 these forces is the force required to operate the vehicle (“ motor” force and friction brake force). motor brake friction drag inertia c b F F F F F F lim + = + + + Equation 4 7 The individual forces can be expressed according to Equation 4 8 to Equation 4 13. Solving Equation 4 7 to 4 13 for the vehicle velocity and then integrating yields an equation for the vehicle velocity v. The force necessary to accelerate or decelerate the vehicle is the force applied to the vehicle by the electric motor plus the braking force due to the mechanical brakes of the vehicle ( left side of Equation 4 7). The applied motor torque is converted to a linear acceleration force accessing the vehicle. The same has been done for the brake force; although in reality this brake force is applied to the wheels, the model assumes a linear braking force that decelerates the vehicle directly ( Equation 4 8). Maximum braking force [ N] Driver request for braking [ 1] Wheel torque introduced by the motor [ Nm] Wheel radius [ m] Force induced by the friction brakes [ N] Force induced by the electric motor [ N] : max max = = = = = = + = + ⋅ brake wheel wheel brake motor brake wheel wheel motor brake F q T r F F where q F r F F T Equation 4 8 The friction term represents the friction due to tire resistance and friction in the wheel bearings ( Equation 4 9). 22 Except information flow. 70 vehicle velocity [ m/ sec] friction coefficient increasing with the square of the velocity [ m sec ] friction coefficient increasing linear with velocity [ m sec] friction coefficient independant of velocity [ 1] gravity [ m sec ] vehicle mass [ kg] : ( )  2 2 2  1 1  2 2 1 2 = = ⋅ = ⋅ = = ⋅ = = ⋅ ⋅ + ⋅ + ⋅ v g m where F m g v v friction μ μ μ μ μ μ Equation 4 9 The aerodynamic drag is considered according to Equation 4 10. frontal area[ m ] coefficient of drag [ 1] density of air [ kg m ] : 2 1 2  3 2 = = = ⋅ = ⋅ ⋅ ⋅ ⋅ A c where F c A v w drag w ρ ρ Equation 4 10 The force necessary to overcome the vehicle inertia is the sum of the force necessary for accelerating the vehicle mass plus the force necessary for the acceleration of the rotational inertia of the wheels. Wheel speed in [ rad/ sec] Wheel inertia [ kg m ] : 2 = Θ = ⋅ ⋅ Θ = ⋅ + wheel wheel wheel wheel wheel inertia where dt d dt r F m dv ω ω Equation 4 11 The wheel speed and the vehicle velocity are related to each other according to Equation 4 12. This equation assumes that the tires won't slip. In case of tire slip, this Equation has to be modified. wheel wheel r ω = v Equation 4 12 71 Finally, the climbing resistance ( the force required to go uphill or the force gained going downhill) is considered in this model. grade the vehicle needs to overcome [%] : sin tan 1 100 lim = = ⋅ ⋅ − grade where F m g grade c b Equation 4 13 The sum of all forces impacting the vehicle determines, together with the vehicle mass, the vehicle acceleration. Equations 4 7 to 4 13 are used to calculate the vehicle acceleration as a function of time. The integration of the vehicle acceleration results in the vehicle velocity. The required starting value at t= 0 sec represents the vehicle velocity at t= 0 sec. This initial velocity is set to 0 km/ h. Equation 4 14 shows the algorithm for the calculation of the vehicle velocity. Figure 4 5 is the graphical representation in form of a Simulink diagram of this algorithm. The vehicle velocity can be calculated for a given wheel torque. The wheel torque itself depends on the vehicle velocity and is calculated in the block " motor." Because of the non linear relationship between the provided wheel torque and the vehicle velocity, Equation 3 14 cannot be solved explicitly. The braking force Fbrake_ max in Equation 4 14 is less than or equal to zero. 72 q F m g v v grade c A v dt r T r m v t t t brake w wheel wheel wheel wheel ⋅ ⋅ ⋅ ⋅ ⋅ − ⋅ + ⋅ − ⋅ ⋅ + ⋅ + ⋅ + + Θ = ∫= − 0 2 1 2 _ max 1 2 2 2 1 100 sin tan ( ) 1 μ μ μ ρ Equation 4 14 2 velocity km/ h 1 wheel speed rad/ sec  Kwheel radius  Kwheel inertia  Kvelocity m/ sec in wheel speed [ rad/ sec] 3.6 velocity from m/ sec to km/ h velocity friction force in N friction force1 v elocity f orce in N climbing force force in velocity force out avoid negative velocity v elocity drag f orce in N aero drag Sum resulting wheel torque [ Nm] mechanical brake f orce resulting acc. f orce [ N] wheel speed velocity Results 1/ s Integrator 2 wheel torque Nm 1 braking force N Figure 4 5: Simulink representation of the mechanical vehicle properties. 73 4.3. Component Models 4.3.1. Electric Motor Including Power Electronic Many different motor technologies for electric vehicle drive trains are in use today. Among them are induction motors, permanent magnet brushless dc motors, dccurrent motors, and switched reluctance motors ( Nahmer 1996, Skudelny 1993). Two different modeling philosophies are applied in today’s vehicle models for the modeling of the electric drive train and the power electronics. The first approach is based on fundamental physical principles. Motor torque and speed are calculated based on armature current and field current ( armature current and magnetic field for permanent magnet motors). This approach requires a detailed motor model for each motor technology. A motor model for an induction motor would be fundamentally different from a motor model for a brushless dc motor. The input parameters for this approach are the motor geometry, material parameters, and the electrical parameters of the motor coil and power electronics. Li and Mellor ( Li and Mellor 1999) describe such a modeling approach for the case of a brushless dc motor. 23 The other possible modeling approach is based on static maps for the drive train efficiency in dependence of the motor torque and speed and the maximum motor torque in dependence of the speed and applied voltage. This second approach is followed by Ricardo Consultants ( Heath 1996) and National Renewable Energy Laboratories ( NREL, 1999). This modeling approach is technology independent, e. g. the same model could be used for different motor technologies. Only the motor describing parameters, such as maximum motor torque and maximum motor speed and the above mentioned maps have 23 In the paper, the brushless dc motor is referenced as a brushless ac motor . 74 to be adjusted for each specific motor technology and motor configuration ( size, characteristic). The necessary input data for this approach could be gained on a motor test stand similar to the one described by Nahmer ( Nahmer 1996). For gaining the efficiency map, the motor is operated at one specific operating point ( torque and speed) and the electrical input power is measured. The efficiency is the ratio of mechanical output power over electrical input power. For gaining the map of maximum torque in dependence of speed and voltage, the motor is operated at one operating point ( speed, voltage) and the maximum motor torque the motor is able to deliver is measured ( increase of the mechanical load until the motor speed drops while holding the terminal voltage constant). Due to the significantly shorter runtime and better availability of the necessary input data, the second modeling approach with static maps has been chosen in this dissertation. For modeling of the motor transient characteristics, the static approach has been modified and incorporates the mechanical time constant implied by the motor inertia. This time constant is the dominant time constant and exceeds the electrical time constant due to the coil inductivity and resistance, by far which is on the order of microseconds ( Nahmer 1996). The modeling based on static maps allows also the incorporation of all currently applied motor technologies without changing the model structure. Interface: On the electrical side the motor model including power electronics interfaces with the dc power source ( battery system, fuel cell stack, or ultra capacitor system). The variables at this interface are the dc current and the dc voltage. On the mechanical side the motor shaft interfaces with the transmission. Interfacing variables are the shaft torque 75 and the shaft speed ( Figure 4 6). On the information side ( data bus) the motor receives the brake pedal position ( only for hybrid vehicle designs with electrical energy storage) and the acceleration pedal position. However, if the motor controller is excluded from the actual motor, as shown in Figure 4 6, the motor receives a signal for the requested motor torque from the motor control algorithm. brake pedal position acc. pedal position dc bus voltage motor speed  + xx// efficiency map maximum motor torque dc drive train current net motor torque motor control algorithm inner torque motor η dt Θ⋅ dω Figure 4 6: Structure of the motor block including power electronics and motor control algorithms. The characteristics of the motor and the power electronics are inside the by the dashed line marked area. Outside of this area is the motor control algorithm that takes the inputs shown and derives a signal for the requested motor torque. Parameters: For steady state operation, the motor including the power electronics is modeled with a two dimensional efficiency map ( Figure 4 7). This map shows the overall motor and drive train efficiency as a function of motor speed and motor torque for steady state conditions. The influence of voltage fluctuation on the peak efficiency and shape of the islands of constant efficiency is minor and can be neglected ( Nahmer 1996). However, if 76 the motor is operated at lower voltages, not all operating points shown on the map are valid operating points. With decreasing voltage, the operating regime shrinks to the area within the lines of maximum torque shown in the Figure 4 8. Figure 4 8 shows a map for the maximum motor torque as a function of motor speed and terminal voltage. Both maps are derived from experiments for the case of a 75 kW induction motor. The efficiency map includes the power electronics. Therefore the maps represent not only the motor properties but also the properties of the combined system of power electronic and electric motor including control algorithm, such as torque limitation at lower voltages. 0 2000 4000 6000 8000 10000 12000  300  200  100 0 100 200 300 Motor speed [ rpm] Motor torque [ Nm] 0.92 0.92 0.8 0.85 0.88 0.9 0.91 0.92 0.92 0.91 0.9 0.88 0.85 0.8 0.7 0.5 0.7 0.5 Motor Mode Generator Mode Figure 4 7: Motor efficiency map. 77 0 1000  300 2000 3000 4000 5000 6000 7000 8000 9000 10000  200  100 0 100 200 300 200 V 400 V 250 V 300 V 350 V 200 V 250 V 300 V 350 V 400 V Motor Mode Generator Mode Motor torque [ Nm] Motor speed [ rpm] 3000 Figure 4 8: Map of maximum torque. Besides the maps shown in Figure 4 7 and Figure 4 8, the only other parameters that characterize the electric motor including the power electronics are the rotational motor inertia and the motor mass. The motor inertia determines mechanical transients of the motor, e. g. the motor acceleration if no mechanical load is applied, and the motor mass influences the overall vehicle mass and with this the vehicle acceleration for a given configuration. Algorithms: For modeling purposes only the upper half ( 1st and 2nd quadrant) of both maps has been measured ( acceleration mode). The lower half ( regenerative braking) has been derived by mirroring the upper half. Because of friction within the motor bearings and frictional losses due to the aerodynamic drag ( rotor) this assumption is not 100% correct. While in the acceleration mode the frictional losses reduce the available net motor shaft 78 torque, in the regenerative braking mode the frictional losses would provide additional shaft torque ( Figure 4 9 and Figure 4 10). Only if the mechanical frictional losses could be neglected would the mirroring technique provide exact results. However, if the motor is not cooled by forced air through a fan sitting on the motor shaft, the frictional losses are much smaller than the provided net power. For this case the mirroring technique is justified and the maximum torque in the generator mode equals the maximum motor torque for the same speed and terminal voltage. electric motor electric power electrical losses mechanical losses ( friction in bearings and aerodynamic drag) net shaft power Figure 4 9: Power flow and losses in acceleration mode. 79 electrical losses electric motor electric power mechanical losses ( friction in bearings and aerodynamic drag) net shaft power Figure 4 10: Power flow and losses in regenerative braking mode. The motor efficiency during acceleration phases is stated in Equation 4 15. electrical power ( dc)[ W] accessable net mechanical power [ W] motor efficiency in acceleration mode [ 1] : _ motor _ motor = = = = el mech net el mech net P P where P P η η Equation 4 15 During phases of regenerative braking the motor efficiency is stated in Equation 4 16. motor efficiency in regenerative brake mode [ 1] : regen _ regen = = η η where P P mech net el Equation 4 16 The discussion above assumed the steady state operation of the electric motor. For the transient case, the motor inertia has to be considered ( Equation 4 17). The usable motor torque supplied to the transmission is the motor shaft torque generated by the motor minus the product of motor inertia and angular shaft acceleration. During phases of vehicle acceleration, the torque supplied to the wheels is reduced and less torque is available for the acceleration of the vehicle. During phases of deceleration, the motor 80 inertia effectively acts as an energy storage that has to be discharged for the deceleration of the vehicle. The stored energy has to be dissipated in the brake system or converted into electrical energy if the vehicle concept allows for regenerative braking. Motor shaft speed [ rad/ sec] Motor shaft torque [ Nm] Motor inertia [ kg m ] Torque supplied to the transmission[ Nm] : 2 = = Θ = ⋅ = = − Θ ⋅ motor motor motor trans motor trans motor motor T T where dt T T d ω ω Equation 4 17 The torque supplied by the motor to the transmission depends on the request of the motor control algorithm multiplied by the maximum torque the motor is able to provide ( Figure 4 8). It is stated in Equation 4 18. The request of the motor control algorithm is derived from the inputs to this algorithm such as driver request and torque reduction due to high or to low voltage. The motor controller and the embedded control algorithms are described in the next chapter. Bus voltage [ V] Torque request motor controller [ 1] voltage and speed [ Nm] ( , ) Max. motor torque at this specific : ( , ) _ max _ max = = = = ⋅ dc motor dc motor motor motor dc motor V p T V where T T V p ω ω Equation 4 18 On the electrical side of the motor, the dc motor current is derived by balancing mechanical power at the motor shaft and electric power at the motor terminals. The motor torque times the motor speed is equal to the product of drive train voltage times drive 81 train current times motor efficiency. Solving this power balance results in Equation 4 19 for the drive train current on the dc side of the power electronics if the motor is in acceleration mode. Motor efficiency [ 1] Dc current into drivetrain [ A] : ( ) ( , ) _ , _ = = ⋅ ⋅ = motor motor dc dc motor motor motor motor motor dc motor motor dc I where V T I T V η η ω ω ω Equation 4 19 The motor efficiency in Equation 4 19 is taken from the motor efficiency map in Figure 4 7 for positive torque and positive speed ( 1st quadrant). For the case of regenerative braking in hybrid vehicle designs, Equation 4 19 changes to Equation 4 20. Motor efficiency in the mode of regenerative braking [ 1] : ( ) ( , ) , _ = ⋅ ⋅ = regen dc regen motor motor motor motor dc motor motor dc where V T I T V η η ω ω ω Equation 4 20 The motor efficiency in Equation 3 20 is taken from the motor efficiency map in Figure 4 7 for negative torque and positive speed ( 4th quadrant). 82 4.3.2. Motor Controller and Motor Control Algorithm According to the modeling philosophy, the control algorithms are separated from the component descriptions. This principle is also followed through for the electric drive train. The distinction allows greater flexibility and the use of advanced techniques such as rapid prototyping. The motor control algorithm determines how the acceleration pedal position and the brake pedal position inputs determine the state of the electric motor, e. g. how much torque is requested. In addition to this “ basic” functionality a number of safety and convenience features could be programmed and their impact on the vehicle characteristics tested. Generally, the algorithms could be either programmed in the vehicle controller or in the motor controller. From a pure modeling point of view the difference is not significant. However, in real vehicles, in some cases the supplier situation might require that “ know how” be kept outside of the motor controller. If this is the case, specific motor control algorithms could be realized in the vehicle controller. In this work, it has been decided to place all motor related control algorithms into the motor controller. Figure 4 11 shows the graphical representation of the algorithm. The overall algorithm splits up into two parts. The first part is responsible for the operation of the electric drive system in the motor mode. The second part is responsible for the operation of the electric drive system in the generator mode. The latter one is only active in hybrid configurations that allow for the regeneration of mechanical power during braking. 83 In the motor mode the relevant input variables are the motor speed, the motor temperature ( or the temperature of the cooling system), the voltage at the dc side of the power electronics, and the acceleration pedal position. In the generator mode the relevant input variables are the terminal voltage at the dc side of the power electronics, the motor speed, the motor temperature, and the brake signal indicating the request for regenerative braking. In the motor mode the normalized acceleration pedal position requests the fraction of the peak motor torque available. This peak motor torque is a motor constant and is the maximum torque the drive train is able to provide at zero speed and maximum dc voltage at the dc side of the power electronics. This, by the driver requested torque value, can be reduced by several factors: • If the motor speed is too high, e. g. in downhill situations, the motor centrifugal forces accessing the rotor increase and this increase could potentially damage the rotor. Therefore it is necessary to limit the accelerating motor torque beyond a maximum speed but below the critical motor speed that causes damage to the motor. • If the motor temperature is too high, e. g. the losses in the electric motor led to an increase in the motor temperature above the critical temperature. • If the supply voltage is too low. This function is not for the protection of the electric motor but for the protection of the power source ( fuel cell stack, battery or ultracapacitor). A too low voltage increases the possibility of cell reversal and with this a potential damage at the supply side. 84 In the generator mode the normalized electric brake signal derived from the normalized brake pedal position24 determines the fraction of the maximum torque the motor is able to provide in the generator mode. This peak generator torque is the peak torque the drive train is able to provide in the generator mode at zero speed and maximum voltage. It is approximately the same torque as the maximum motor torque but with the opposite sign. Just as in the motor mode, in the generator mode the requested torque could be reduced and increased by several factors: • if the voltage at the dc terminals of the power electronics is too high the generator torque and with this the recharged power needs to be decreased. This functionality protects the battery or ultra capacitor storage from overcharging. • if the temperature of the drive train or the associated cooling system is too high the torque in the generator mode needs to be reduced to avoid damage • if the motor speed is too high, e. g. in downhill situations, the increasing centrifugal forces could destroy the electric drive train. To protect the drive train the generator torque could be increased if the energy storage could accept the additional power. The derived acceleration torque request ( in the motor mode) or the brake torque request for the braking mode is then compared to the actual torque the drive train provides. The result of this comparison is fed into a Proportional – Integral controller ( PI – controller). The output of this controller is limited to upper and lower boundaries and filtered through a first order transfer function, which represents low pass characteristics of the control algorithm to avoid the impact of noise. Finally, the result of this algorithm 24 See chapter “ Vehicle controller.” 85 is the output of the motor controller and determines how much of the motor torque available is requested. An additional function, not realized yet but possible to add, is the mimic of the compression torque of an IC engine vehicle. Because of the fact that electric drive trains have very few frictional losses, the idle characteristics of electric vehicles and IC engine vehicles are different. IC engine vehicles decelerate if the acceleration pedal is released due to significant air compression losses in the engine. In contrast, electric vehicles don’t show this deceleration because no compression losses are present and other frictional losses are small compared to the compression losses. Thus, for the driver of electric vehicles, unfamiliar behavior might lead to driver decisions less optimal for the overall energy consumption of the vehicle. If the driver sees an obstacle, e. g. a red light, he releases the acceleration pedal. However, the vehicle decelerates at a much slower rate than he is used to in IC engine vehicles. It is therefore possible that he approaches the obstacle faster than he thought and is forced to perform a rapid ( last minute) braking maneuver to avoid a collision. In this rapid braking maneuver most of the kinetic energy stored in the vehicle mass is dissipated into heat in the friction brakes and not recovered by generatoric braking. The overall energy balance would be more optimal if the driver had decided to start a gentle braking maneuver as early as possible and recovered the maximum of the kinetic energy stored in the vehicle with generatoric braking. However, this driver behavior is unlikely because it is different from the conventional vehicles. For driver assistance, a function that automatically switches the drive train into the generator mode if the acceleration pedal is released could be implemented. In this case, the 86 requested brake torque simulates the compression losses of an IC engine vehicle. The torque could be constant and speed independent or varying with vehicle speed. motor ( speed to high) max. brake torque XXXX voltage ( to low) 1 Tp+ 1 proportionalintegral controller saturation filter +  actual motor torque acc. signal brake signal XXXXX + + voltage ( to high) max. acc. torque temperature motor speed ( to high) requested torque + + + y y1 yout Figure 4 11: Motor control algorithm. Equations 4 21 to 4 26 show the motor control algorithm illustrated in Figure 4 11 in mathematical form. During regenerative braking the requested torque is computed according to Equation 4 21. 87 ( ) temperature variable ( ) reduction factor due to high temperature ( ) reduction factor due to high terminal voltage maximum motor torque during regenerative braking ( , ) additional brake signal for simulating compression friction ( ) additional brake signal if motor speed is to high brake signal generated by vehicle controller requested torque for the mode of regenerative braking : ( ) ( ) ( ) ( ) _ _ min max_ _ _ _ _ max_ _ min _ = = = = = = = = = − + ⋅ ⋅ ⋅ ϑ ϑ ϑ temperature high voltage high ter al regen idle speed high motor request regen request regen speed high motor idle regen voltage high ter al temperature high r r V T p v q p n p T where T p p n p v T r V r Equation 4 21 During phases of acceleration the requested motor torque is calculated according to Equation 4 22. ( ) reduction factor due to low terminal voltage [ 1] maximum motor torque during acceleration [ Nm] acceleration signal generated by the driver [ 1] requested torque in the acceleration mode [ Nm] : ( ) ( ) ( ) _ min max_ _ _ max_ _ _ min _ = = = = = ⋅ ⋅ ⋅ ⋅ voltage low ter al accel request accel request accel accel speed high motor voltage low ter al temperature high r V T q T where T q T r n r V r ϑ Equation 4 22 The requests for acceleration and braking are summed25 and from the combined request the actual motor torque is subtracted. The difference between the requested and actual motor torque is the error and fed into the proportional integral controller ( Equation 4 23). The output of this controller is limited to values between – 1 ( for maximum generatoric braking and + 1 ( for maximum acceleration) and then fed through a first order transfer function ( Equation 4 24 and 4 25). This transfer function can be interpreted in several ways: 25 Normally either the request for braking or for acceleration is zero. However, the possibility that the driver presses the acceleration pedal and the brake pedal at the same time is not excluded. 88 First it accounts for the filter time constants of the analog input low pass filters in a real power electronic design. Second it accounts for the time constant imposed by the motor coil inductivity and resistance. The output of the motor control algorithm could be interpreted as an analog signal that determines the state of the power switches and therefore controls the average motor current. ( )( ) T actual motor torque [ Nm] K Gain proportional integral controller [ 1/ Nm] Time constant of proportional integral controller [ sec] intermediate value [ 1] : actual MC MC _ _ _ _ = = = = + + − + − ⋅ = ⋅ τ τ y where T T T dt d T T T T dt dy K request brake request accel actual request brake request accel actual MC MC MC Equation 4 23 After the limitation block the intermediate value y changes to the intermediate value y1. intermediate request variable : 1 1 1 1 1 1 1 1 1 1 = = ≤ = ≥ = < < y where y  if y  y if y y y if  y Equation 4 24 Finally the output variable determining the requested motor torque is stated in Equation 4 25. The variable yout determines the requested fraction of the maximum motor torque available. 89 ( ) request variable for motor torque [ 1] filter time constant [ sec] : ( ) ( ) ( ) 1 = = ⋅ + = y t T where y t y t dt T dy t out filter out out filter Equation 4 25 90 4.3.3. Transmission The transmission modeled in this work is a 1 speed transmission including differential. Input variables are the motor shaft speed and the motor shaft torque. The output variables are wheel torque and wheel speed ( Figure 4 12). Figure 4 12: Block diagram of the transmission model. Similar to the electric drive train, the transmission translates energy flows in both directions. During phases of acceleration or cruising with constant speed the energy flow is from the motor to the wheels. During phases of deceleration in hybrid designs the energy flow is reversed from the wheels to the electric motor. The efficiency map has to describe both energy flow directions. Assuming that the motor speed and vehicle speed in this model are always positive, the two directions of energy flow result in a positive torque during acceleration phases and a negative torque during phases of regenerative braking ( in hybrid designs only). trans η motor shaft torque motor speed wheel torque transmission ratio wheel speed 91 Transmission ratio [ 1] Wheel torque [ Nm] T Motor shaft torque [ Nm] Mechanical power at the motor shaft [ W] Mechanical power at the wheels [ W] Transmission efficiency in regenerative brake mode [ 1] : _ _ _ _ trans_ motor _ _ _ _ trans_ motor = = = = = = ⋅ = = i T P P where T i T P P trans wheel trans motor trans motor trans wheel trans motor trans wheel trans motor trans wheel η η Equation 4 26 Transmission efficiency in regenerative brake mode [ 1] : trans_ regen _ _ _ _ trans_ regen = ⋅ = = η η where T T i P P trans wheel trans motor trans wheel trans motor Equation 4 27 Equations 4 26 and 4 27 describe the efficiency for both cases. The model assumes that the friction losses in the transmission are the same for both cases. These assumptions allow mirroring the 1st quadrant of the map ( positive torque and positive speed) into the 4th quadrant ( negative torque, positive speed). The complete efficiency map for the transmission is shown in Figure 4 13. 92 0 2000 4000 6000 8000 10000 12000  300  200  100 0 100 200 300 Shaft speed [ rpm] Shaft Torque [ Nm] 0.96 0.95 0.94 0.930.92 0.93 0.92 0.94 0.95 0.96 Motor Mode Generator Mode Figure 4 13: Efficiency map of the 1 speed transmission including differential. The inertia of the transmission is not explicitly considered in the transmission block. However, the transmission inertia can be transformed without any constraints either to the wheel side and added to the wheel inertia or to the motor side and added to the motor inertia. Equations 4 28 and 4 29 describe the transformation of the rotational inertia to the wheel side or to the motor side for the case of the two stage transmission ( reduction gear and differential). Figure 4 14 shows the rotational inertias at each stage. 93 wheels i1 i2 motor 1 Θ 2 Θ 3 Θ Figure 4 14: Schematic of the transmission. i Reduction ratio of the differential stage [ 1] i Reduction ratio of the reduction stage [ 1] Inertia of transmission components spinning with wheel speed [ kg m ] reduced by the ratio i1 [ kg m ] Inertia of transmission components spinning with the motor speed Inertia of transmission components spinning with motor speed [ kg m ] Total transmission inertia transformed to the motor side [ kg m ] : 1 1 2 1 2 3 2 2 2 1 2 _ _ 2 3 2 2 2 1 _ _ 1 = = Θ = ⋅ ⋅ Θ = Θ = ⋅ Θ = ⋅ Θ = Θ + ⋅ Θ + ⋅ Θ trans motor side trans motor side where i i Equation 4 28 ( ) to the wheel side [ kg m ] total transmission inertia transformed : 2 _ _ 1 2 2 1 2 _ _ 3 2 ⋅ Θ = Θ = Θ + ⋅ Θ + ⋅ Θ trans wheel side trans wheel side where i i Equation 4 29 94 4.3.4. Fuel Cell System In this work, the term fuel cell system is used to refer to the combined system of fuel cell stack, water and thermal management, air supply ( including compressor and expander), and fuel processor ( including reformer, clean up stages, and the burner for the anode off gas). Origin and Development The individual component models that comprise the overall fuel cell system have different origins. Springer ( Springer 1993 and 1998) described the fuel cell model fundamentals on the cell level. Friedman ( Friedman 1998) took the original Springer model, expanded it to a complete stack model and programmed this into SIMULINK. Cunningham ( Cunningham 1999) developed an air supply model for a direct hydrogen vehicle. Combining the stack model and the air supply model Friedman ( Friedman 1999) and Cunningham ( Cunningham 1999) developed an optimal operating strategy for the overall system of fuel cell stack and cathode air supply for the direct hydrogen case. Later, this initial model was expanded to cover the cases of indirect methanol fuel cell systems and indirect hydrocarbon systems ( Friedman 2000). In addition, Cunningham discussed the implications of an additional expander into the air system of a PEM fuel cell engine ( Cunningham 2000). Badrinarayanan developed a water and thermal management system, addressing the cooling loads and the issue of water sustainability. In a second step, Badrinarayanan added water and thermal management implications to the initial optimized operating strategy ( Badrinarayanan 2000). Friedman ( Friedman 2001) provided a complete discussion of the optimal control strategy, including water and th
Click tabs to swap between content that is broken into logical sections.
Rating  
Title  Analysis tool for fuel cell vehicle hardware and software (controls) with an application to fuel economy comparisons of alternative system designs 
Subject  TL221.15.H38 2001; Hybrid electric vehiclesCalifornia.; Fuel cells. 
Description  Thesis (Ph. D)University of California, Davis, 2001.; Includes bibliographical references (p. 249254). 
Creator  Hauer, KarlHeinz. 
Publisher  Institute of Transportation Studies, University of California, Davis 
Contributors  University of California, Davis. Institute of Transportation Studies. 
Type  Text 
Language  eng 
Relation  Also available online.; http://worldcat.org/oclc/57673006/viewonline; http://pubs.its.ucdavis.edu/publication_detail.php?id=371 
DateIssued  [2001] 
FormatExtent  iv, 275 p. : col. ill., col. charts ; 28 cm. 
Transcript  i Analysis Tool for Fuel Cell Vehicle Hardware and Software ( Controls) with an Application to Fuel Economy Comparisons of Alternative System Designs By Karl Heinz Hauer Dipl. Ing. ( University of Braunschweig, Germany) 1990 Dissertation Submitted in partial satisfaction of the requirements for the degree of Doctor of Philosophy in Transportation Technology and Policy in the Office of Graduate Studies of the University of California Davis Approved: Committee in Charge 2001 ii Meinem Vater iii Table of Content 1. INTRODUCTION AND PROBLEM CONTEXT .................................................................... 1 2. LITERATURE REVIEW........................................................................................................ 5 2.1. Introduction................................................................................................................... ................... 5 2.2. Survey and Discussion of the existing vehicle models .................................................................. 11 2.2.1. The HY ZEM ( Hybrid Zero Emission Mobility) Model .......................................................... 14 2.2.2. The PNGVSAT ( Program for New Generation Vehicles Systems Analysis Toolkit) Model... 18 2.2.3. The Advisor ( Advanced Vehicle Simulator) Model ................................................................. 26 2.2.4. The UC Davis Hydrogen ( 1998 Version) Model...................................................................... 32 2.2.5. The Simplev ( Simple Electric Vehicle Simulation) Model....................................................... 36 2.3. Summary........................................................................................................................ ................. 38 3. APPLIED MODELING METHODOLOGY .......................................................................... 44 3.1. General Aspects........................................................................................................................ ...... 44 3.2. Mathematics ............................................................................................................................... .... 46 3.2.1. Introduction................................................................................................................... ........... 46 3.2.2. Example and Transfer into SIMULINK.................................................................................... 56 4. MODEL DESCRIPTION...................................................................................................... 58 4.1. Modeling Structure and Goals....................................................................................................... 58 4.2. Vehicle Model.......................................................................................................................... ....... 60 4.2.1. Drive Cycles and Driver Model ................................................................................................ 61 4.2.2. Physical Vehicle Model ............................................................................................................ 66 4.3. Component Models ......................................................................................................................... 73 4.3.1. Electric Motor Including Power Electronic .............................................................................. 73 4.3.2. Motor Controller and Motor Control Algorithm....................................................................... 82 4.3.3. Transmission................................................................................................................... ......... 90 4.3.4. Fuel Cell System....................................................................................................................... 94 4.3.5. Battery System........................................................................................................................ 128 4.3.6. Ultra Capacitor System........................................................................................................... 140 4.3.7. DC DC Converter ................................................................................................................... 154 4.3.8. Vehicle Controller................................................................................................................... 173 5. MODEL APPLICATION.................................................................................................... 179 5.1. Vehicle Requirements................................................................................................................... 179 5.2. Vehicle Parameters and Vehicle Design...................................................................................... 181 5.3. Component Sizing ......................................................................................................................... 189 5.3.1. Choice and Sizing of the Battery System................................................................................ 189 5.3.2. Choice and Sizing of the Ultra capacitor System ................................................................... 191 iv 5.4. Simulation Results ........................................................................................................................ 197 5.4.1. Load Following Fuel Cell Vehicle Model............................................................................... 198 5.4.2. Battery Hybrid Fuel Cell Vehicle Model ................................................................................ 207 5.4.3. Ultra Capacitor Hybrid Fuel Cell Vehicle Model ( indirect coupling) .................................... 221 5.4.4. Ultra Capacitor Hybrid Fuel Cell Vehicle Model ( direct coupling) ....................................... 228 5.5. Summary of the Simulation Results ............................................................................................ 234 6. VERIFICATION OF THE RESULTS................................................................................. 239 7. SUMMARY AND CONCLUSION ..................................................................................... 245 8. REFERENCES.................................................................................................................. 249 9. APPENDIX....................................................................................................................... 255 9.1. Forwards and Backwards Looking Modeling Approach .......................................................... 255 9.2. Method of Co Simulation ............................................................................................................. 261 9.3. Rapid Prototyping.................................................................................................................... .... 267 9.4. Conversion Factors ....................................................................................................................... 268 9.5. Vehicle Parameters ....................................................................................................................... 269 9.6. Battery and the Battery Controller Parameters......................................................................... 271 9.7. Ultra Capacitor Parameters for the Directly to the Stack Coupled Ultra Capacitor............. 272 9.8. Ultra Capacitor Parameters for the Via Dc Dc Converter to the Stack Coupled Ultra Capacitor ............................................................................................................................... ................... 274 1 1. Introduction and Problem Context The ever growing demand for individual transportation leads to a larger and larger vehicle fleet and a steady increase in vehicle miles traveled ( VMT) ( National Research Council, 1997). Associated with this increase in VMT are increases in air pollution and carbon dioxide emissions, one possible reason for the observed global warming phenomena ( The International Panel on Climate Change, 1995). Although emissions from new conventional vehicles with internal combustion engines and hybrid vehicles with internal combustion engines and additional electric motors are reduced, the air quality standards are not in attainment with federal regulations in many regions in the United States. Especially on the west coast in California with its rapid growth, booming economy, and special weather conditions that promote the formation of ozone, cities like Los Angeles and San Diego battle severe air quality problems ( Lloyd, 1999). In addition, the energy efficiency and related carbon dioxide emissions are still far from the 80 miles/ gallon goal for passenger vehicles set by the Partnership of New Generation Vehicles ( PNGV) and seem to be difficult to achieve with conventional technology. Widely discussed among the alternatives to the internal combustion engine vehicle are fuel cell vehicles. This vehicle type promises not only very clean operation ( up to zero emission operation, but also higher energy efficiency than conventional vehicles without the range limitations associated with battery electric vehicles. 1 Although the fuel cell vehicle has been discussed since the 60’ s ( Sievert 1968), fuel cell vehicles have not been seen as a likely replacement for the internal combustion engine vehicle until recently. In 1994 Daimler Chrysler ( formerly Daimler Benz) introduced the first 2 New Electric Car ( NeCar 1) in a series of five prototype fuel cell vehicles ( Daimler Chrysler 1999). Despite the fact that these vehicles have prototype characteristics they demonstrated one path to a more environmentally friendly passenger vehicle and sparked public interest and a race into the market. Today all major car companies are investing heavily in this new and promising technology with ambitious plans to introduce it into the market ( Panik 1999, GM Europe 1999). Fuel cell vehicle modeling is one method for systematic and fast investigation of the different vehicle options ( fuel choice, hybridization, reformer technologies). However, a sufficient modeling program, capable of modeling the different design options, is not available today. Shortfalls of the existing programs, initially developed for internal combustion engine hybrid vehicles, are: • Insufficient modeling of transient characteristics; • Insufficient modeling of advanced hybrid systems; • Employment of a non causal ( backwards looking) structure; • Significant shortcomings in the area of controls. Modern simulation programs should be capable of serving as tools for analysis as well as development. In the area of analysis, a modeling tool for fuel cell vehicles needs to address the transient dynamic interaction between the electric drive train and the fuel cell system. Especially for vehicles lacking an instantaneously responding on board fuel processor, this interaction is very different from the interaction between a battery ( as power source) 1 Besides hydrogen fueled fuel cell vehicles, battery electric vehicles are the only other zero emission technology available today. 3 and an electric drive train in an electric vehicle design. Non transient modeling leads to inaccurate predictions of vehicle performance and fuel consumption. Applied in the area of development, the existing programs do not support the employment of newer techniques, such as rapid prototyping. This is because the program structure merges control algorithms and component models, or different control algorithms are lumped together in one single control block and not assigned to individual components as they are in real vehicles. In both cases, the transfer of control algorithms from the model into existing hardware is not possible. The simulation program developed in this dissertation recognizes the dynamic interaction between fuel cell system, drive train and optional additional energy storage. It provides models for four different fuel cell vehicle topologies: • A load following fuel cell vehicle; • A battery hybrid fuel cell vehicle; • An ultra capacitor hybrid fuel cell vehicle in which the ultra capacitor unit is coupled via a dc dc converter to the stack; • An ultra capacitor hybrid fuel cell vehicle with direct coupling between fuel cell stack and ultra capacitor. The structure of the model is a causal and forward looking. The model separates the modeling of control algorithms from the component models. The setup is strictly modular and encourages the use of rapid prototyping techniques in the development process. 4 The first half of the dissertation explains the model setup. In the second half of the dissertation, the simulation of different hybrid vehicle designs illustrates the capabilities of the model. This study shows that, from the standpoint of fuel economy improvement, hybrid fuel cell vehicles have a potential advantage over the pure load following fuel cell vehicle. Further, the study shows that among the modeled hybrid vehicles the vehicle with directly to the stack coupled ultra capacitor shows the largest benefit in terms of fuel economy compared to the pure load following design. An additional benefit of this design is that it is the simplest of the three investigated hybrid vehicle concepts. For all of the analyzed hybrid vehicles, the improvement of fuel economy results from the ( averaged over a drive cycle) higher fuel cell system efficiency and the additional feature of regenerative braking. Besides the arrangement of the components, the realized fuel economy benefits depend significantly on the control schemes balancing vehicle performance, fuel cell system characteristics, and stress of the energy storage system. Due to the limited energy storage capacity of the ultra capacitor systems, the two vehicles hybridized with ultra capacitors are especially sensitive to the design of the control algorithms. In addition to the potential improvement of fuel economy, hybrid designs offer the possibility to relax the transient requirements for the fuel cell system and the feature of a rapid cold start in the morning ( increased customer benefit). Although not investigated, each of these two advantages is considered important and could, together with the higher fuel economy, spark the interest in hybrid fuel cell vehicle designs in the near future. 5 2. Literature Review This chapter analyses different fuel cell vehicle models and compares them with each other on a qualitative basis. Quantitatively Hoefgen ( Hoefgen 2001) compares a subset of the models listed in Table 2 3. For the qualitative comparison in this dissertation work first a metric of comparison was established. Second the most commonly discussed models are listed and relationships are identified. Based on the metric of comparison five of the listed modeling programs are described and advantages and disadvantages are highlighted. The comparison concludes that none of the investigated models is satisfactory in terms of modularity ( separation of controls and component models), vehicle configurations modeled, and dynamic capabilities. 2.1. Introduction The generic requirements for a fuel cell fuel vehicle model can be defined as follows and are not different to the requirements of other types of modeling work2. A fuel cell vehicle model has to be physically and mathematically sound. All relevant physical effects have to be considered and the model should stand on mathematical solid ground. Unless these two conditions are fulfilled we cannot rely on the results. In addition to the soundness the scope of the model should also be complete. Complete in this context means that it should enable the modeling of different types of vehicles ( hybrids, non hybrids and different forms of hybrids) and fuel cell systems for different fuels. The resolution of the modeling effort should be high enough to capture all the effects of interest. For example some of the models listed in Table 2 3 simplify the 6 function of regenerative braking so much that the results become extremely inaccurate. In the context of Table 2 1, the resolution or depth of modeling these models provide is not sufficient. Also a fuel cell vehicle model has to be flexible enough to incorporate new trends and technologies without the need of starting from scratch. From a practical point of view: the necessary input data have to be available, the validation of the model should be possible, and the model should support its use as well as the issue of program maintenance. The runtime should be in context of the problem setup. Therefore for more complex questions a longer runtime seems to be acceptable. Last, but not least, the results have to be valid and ( within tolerances) match the experimental results. • Theoretically sound o Physically o Mathematically • Complete scope o Consideration of different vehicle and fuel cell system concepts o Resolution ( are all effects of interest modeled in a sufficient detail) o Flexibility ( is the model flexible enough to incorporate future developments) • Practicality o Are the required input data available? o Validation possible? o Ease of operation o Ease of program maintenance? ( Logical structure) o Runtime • Valid results Table 2 1: Generic modeling requirements 2 The listed requirements are basically taken from John L. Bowman and Moshi Ben – Akiva’s paper “ Activity  Based Travel Forecasting” ( Bowman and Akiva, 1996) but translated into the context of this dissertation work. 7 Requirement Criteria Theoretical soundness Is the model programmed in a forward or backwards approach? 3 Complete Scope • Completeness Is the model employing techniques supporting the coverage of a wide range of vehicle concepts ( scaling, component libraries)? 4 • Resolution Does the model support the method of co simulation? • Flexibility Is the model programmed in a modular way? 5 Practicality • Input data Are all required input data available? • Validation Does the program setup support the method of rapid prototyping? Are component models separated from control algorithms? • Ease of use Is a graphical user interface programmed? Is the documentation complete and useful? Is the runtime reasonable? Is the setup of the model transparent and logical? Valid results All the models investigated in this paper deliver valid results within tolerances. Therefore this requirement is not a measure of comparison. Table 2 2: Translation of the original requirements into objective criteria that could be checked For an objective comparison of the different simulation models the list of requirements in Table 2 1 is not beneficial. Therefore the content of Table 2 1 is translated into a number of key criteria that a “ good” fuel cell vehicle modeling program 3 Limiting the requirement of theoretical soundness to the criteria above assumes that the model does not violate any elementary physical or mathematical laws. This assumption is justified for all of the models looked at in this dissertation. 4 The issue of completeness looks towards the potential of a model to be complete, e. g.; the coverage of all vehicle configurations of interest. Because of the number of possible configurations and the unpredictability of future developments completeness is fulfilled if the model structure supports measures to incorporate a large number of designs. 8 has to fulfill ( Table 2 2). The comparison is looking at these criteria assuming that the incorporation of them into the program guarantees the original requirements in Table 2 1. This systematic comparison emphasizes the ( theoretical) potential of the simulation programs. This first comparison will be supported by a closer look at how much of the theoretical potential has already been realized in the current version of each model. This second measure of comparison is more subjective because of fact that due to the very different modeling approaches a direct comparison of functionality is not possible. However it still provides significant insight into the current state of fuel cell vehicle modeling. After establishing the method of comparison the following paragraphs list the most important ( and most used) electric, hybrid and fuel cell vehicle modeling programs. Among them only the UC Davis hydrogen fuel cell vehicle model has been exclusively developed for fuel cell vehicle modeling. All the other programs incorporate functionality for the simulation of battery electric and IC hybrid vehicles. 5 Flexibility describes the possibility to change the model structure in a time efficient manner. A modular structure supports flexibility. 9 Table 2 3: Overview about alternative fuel vehicle models In addition to the vehicle models listed in Table 2 3 other models are under development or already completed. Most of these other, not listed, models are either propriety and internally developed by automotive manufacturers or contractors and only very limited information is publicly available or they are not completed yet. For this reason these models are not discussed in this dissertation work. The next section compares the most important models listed in Table 2 3 with regard to the criteria explained in the appendix and derives, based on this comparison, the need for a new vehicle model that will be described in this dissertation work. The comparison ends in a summery and concludes that a new fuel cell vehicle model is necessary. Name Source Backwards/ Forwards Fuel Cell Vehicles ? Year HYZEM Ricardo Consulting Engineers Ltd. Forward No 1995 Elvis Southwest Research Institute Backwards No 1993 Path Southwest Research Institute Forward No 1996 1997 PSAT Southwest Research Institute and Argonne National Laboratories Forward Yes 1996 1999 Advisor National Renewable Research Laboratory ( NREL) Backwards Yes 1994 2000 Simplev Idaho National Engineering and Environmental Laboratory Backwards No 1990 1997 Avte UC Davis, ITS Backwards No 1996 UC Davis – Hydrogen UC Davis, ITS Backwards Yes 1999 10 The appendix provides the necessary background information about three major issues associated with fuel cell vehicle modeling. They are closely tied to the list of model requirements at the beginning of the chapter and have their origin in this list. The issues discussed in the appendix are: • The choice of the modeling approach. Two different modeling approaches have been realized in the existing fuel cell vehicle models. The forwards looking and the backwards looking approach. The physical and mathematical soundness of the model is significantly depending on the choice of the modeling approach. • The incorporation of co simulation techniques. Co simulation techniques are the parallel operation of two different modeling programs, e. g. Matlab/ Simulink for the overall vehicle and Saber for the electric drive train within the vehicle. Co Simulation allows a higher depth of modeling or a higher resolution. • The incorporation of rapid prototyping and hardware in the loop features. Both methods are well known development techniques for shortening the development time. From a modeling point of view the benefits are the fact that ( through the involvement of the simulation program in the development process) a mutual validation of the model at all development stages occurs, and not only at the end of the development process. 11 2.2. Survey and Discussion of the existing vehicle models Five different development lines could be identified looking at the model properties and the historical development of the models ( Figure 2 1). These are: • Ricardo Consultants with the Hyzem program system ( Heath, 1996 and Sadler, 1998). • Southwest Research Institute ( SWRI) with the modeling program systems Elvis, Path, Apace and their final product PSAT ( McBroom, 1996). PSAT has been originally developed as the modeling tool for the Partnership of New Generation Vehicles but will be soon made publicly available from Argonne National Laboratory for registered researchers6. • National Renewable Energy Institute with the program system Advisor ( National Renewable Energy Laboratories, 2000). Since recently, Argonne National Laboratories is responsibility for the development lines PSAT and Advisor and incorporates them into a single graphical user interface for the ease of use. • UC Davis starting originally with the Advanced Vehicle Test Emulator ( AVTE) and an ( AVTE based) direct hydrogen fuel cell vehicle model ( Fuel Cell Modeling Group, 1999). Both models are derived from Advisor. In addition to this modeling effort, UC Davis started within the fuel cell vehicle modeling project a new forward looking fuel cell vehicle model that incorporates currently the fuels hydrogen, indirect methanol and indirect gasoline in hybrid and non hybrid versions. 6 The release, for registered researchers only, is scheduled for November 2000. 12 • Idaho National Engineering and Environmental Laboratory ( INEEL) with Simplev. The program has only historical meaning  it was phased out in 1997 ( Idaho National Engineering and Environmental Laboratory, 1993). The final product of each of these development lines will be taken and benchmarked according to the criteria listed in Table 2 2. In addition the fuel cell vehicle modeling capabilities will be listed qualitatively, e. g.; which type of fuel cell vehicle models are included ( hybrids, fuel choice). Finally a statement about the current stand of the model with respect to depth of analysis will be made. For example, some of the vehicle models include a static fuel cell system model based on maps only while other models take dynamic aspects into account. Based on this comparison it will be concluded that a new fuel cell vehicle simulation model is necessary. 13 Elvis 1990 1995 2000 Path Psat Apace Hyzem Simplev Generation 1 3 Advisor Generation 1 3 Avte DH2 INEEL IMFCV NREL UC Davis SWRI Ricardo merge 4 models remain Argonne National Lab. Figure 2 1: Model evolvement and history 14 2.2.1. The HY ZEM ( Hybrid Zero Emission Mobility) Model HY ZEM has been programmed by Ricardo Consultants and is not commercially available as an off the shelf programming package7. The program will always be delivered in a project specific form as part of a development contract. The model is programmed in Simulink in a causal, forward looking, approach ( Heath, 1996, Sadler, 1998). Figure 2 2 shows the program setup ( highest level) for the example of a series hybrid electric vehicle with internal combustion engine. The presence of a “ driver” block indicates the forward looking approach. Besides the driver the model consists of one main control Block “ SH controller” and component blocks for every major component. Each component model has three input and three output ports, each port could also be vectorized meaning it could combine several individual variables. The inputs and outputs are listed in Table 2 4. Control inputs and outputs are signals with no energy associated with them for example the value of a voltage or a current. Power outputs/ inputs connect blocks on the physical level. One example is the battery voltage connected to the motor block. This connection is physical and could therefore be seen in a real vehicle. The third pair of inputs/ outputs is also a physical connections but through these connections feedback loops among components are established. One example for such a feedback loop is the feedback of the motor current to the accessory block and finally to the battery block. Through these feedback loops dynamic behavior is incorporated into the model. Hyzem is set up in a modular form and includes a library for mechanical, electrical and control modules that all employ the same input / output 7 Personal email exchange with Ricardo Consultants in October 2000 15 structure ( Heath 1996). Input data for the modeling process are standard vehicle parameters and steady state maps for operating point dependent component properties ( Sadler, 1998). Input/ Output Label Comment Input 1 Controls input Signals from the controller block Input 2 Power input Input values from a previous block Input 3 Feedback input Feedback values from a connected block Output 1 Controls output Signals looped to the controls block Output 2 Power output Output values to a succeeding block Output 3 Feedback output Feedback values to a connected block Table 2 4: Overview of component models inputs and outputs. No information could be found about the possibility of co simulation. However in principle the causal, forward looking, approach supports co simulation. Also the program package “ wave” ( Ricardo Consultants, 2000) has been suggested by Ricardo Consultants to UC Davis for modeling the airside of a fuel cell system. Because of this suggestion it could be assumed that Ricardo also combines ( or attempts to combine) Hyzem and wave8. Because of the fact that the model is not off the shelf available, and is only provided as part of a larger contract, the issue of “ ease of use” becomes secondary. For example a graphical user interface, complete documentation and straight logic is not essential if the user gets assistance from Ricardo. The model has been validated with a Volkswagen Golf IC hybrid vehicle and a Peugot 106 electric vehicle ( Heath, 1996). 8 Personal email exchange between members of the fuel cell modeling group ( UC Davis) and Ricardo 16 Modeling results for an indirect methanol fuel cell vehicle in load following and load leveling ( hybrid) form have been presented by Sadler ( Sadler, 1998). The model includes start up characteristics and emissions although it is not clear how detailed the model is9. Strengths: • Strong modular approach using predefined components from a library ( Heath, 1996), • The model considers the dynamic interaction ( feedback) between components ( Heath, 1996). Weaknesses: • The combination of the library modules leads to a difficult to oversee system diagram, which does not always reflects the causalities within the vehicle. ( Example: In the electric vehicle model the battery voltage does not directly feed back into the motor block). • Control algorithms are not assigned to the individual components, such as the battery controller to the battery block. Instead the control algorithms are summarized in one single control block, which embeds the controls for all components. Embedding the controls of all components in one block makes rapid prototyping as one measure of continuous validation impossible10. However Ricardo claims that the recent versions are supporting rapid prototyping. • The levels of information flow and physical component interaction are not separated. 9 A version including fuel cell vehicle models was not available 10 This is true for the 1996 version of HYZEM. However for recent versions of HYZEM Ricardo Consultants claim the possibility of rapid prototyping. Because neither the software itself nor any detailed information has been made available the statements could not be verified. 17 Figure 2 2: Hyzem vehicle model ( most upper level of a series hybrid electric vehicle) vehicle vehicle traman traman motblack motblack loaaux loaaux genblack genblack engdiet engdiet battery Sum battery consh SH Controller Notes Driver & cycle 18 2.2.2. The PNGVSAT ( Program for New Generation Vehicles Systems Analysis Toolkit) Model The program PNGVSAT or PSAT has been originally developed by the Southwest Research Institute. Since August 2000 Argonne National Research Laboratories is responsible for program maintenance and further development. Since November 2000 PSAT 4.0 is available for registered researchers in the field of hybrid and electric vehicles ( Rousseau 2000). Figure 2 3 shows the most upper level of the model of an indirect methanol fuel cell vehicle with additional battery storage. The existence of a driver model ( the icon showing the steering wheel in Figure 2 3) indicates a causal, forward looking, modeling approach. The program documentation confirms the separation of driver and vehicle and the forward looking modeling approach ( Argonne National Laboratories 2000). The general structure is similar to the model developed by Ricardo Consultants. Specific similarities are: • A driver controls the velocity of the vehicle, • One single controls block organizes the component interaction ( Controller), • Each individual component block employs three inputs and three outputs, which could be interpreted identical to the inputs and outputs defined by Ricardo Consultants. However the labeling in PSAT is different and orientated to the physical value each port carries, e. g. the current going into the battery is labeled “ current in”, the resulting voltage at the battery terminals is labeled “ voltage out”. • Inputs and outputs of each block can be vectorized.. 19 Despite these similarities PSAT employs more blocks than Hyzem. While Hyzem employs only one block modeling the drive train between motor shaft and wheels PSAT uses four blocks for the same task. PSAT models this part of the drive train with much higher accuracy than all other models compared in this dissertation work. One example is tire slip including modeling weight transfer, a feature important for modeling vehicles that exhibit a high power – weight ratio, such as the EV1. The incorporation of advanced modeling techniques, such as co simulation is possible ( though not realized) in version 4.0. Although PSAT follows the general setup of Hyzem it does not strictly separate component models from control algorithms. Because of this PSAT 4 does not qualify for the employment of rapid prototyping. The fast and mutual validation of the program in parallel to the development process of a physical vehicle employing rapid prototyping is not possible. Another consequence of the mix of control algorithm with component models is that a validation on the component level is not possible. One example for this is the validation of the stand alone battery model. The battery model includes current limitations that are not part of the physical battery but realized in the motor controller software and power electronics. The effect is that even a short circuit of the battery model would not result in a voltage drop to zero volts and a current that exceeds the operational limits. In other words a largely oversized motor would still work fine with the battery without noticing that it draws a power much beyond what the battery is able to deliver. In fairness, is has to be said that PSAT as a complete model does not calculate anything wrong. However the result of the merge of a battery model with motor controller 20 characteristics is a difficult to oversee structure that makes changes and program maintenance time consuming. A helpful feature of PSAT is the graphical user interface ( Figure 2 4). This graphical user interface is very similar in appearance and logic to the one used in Advisor 3.0. It supports the following functions: • Choice of vehicle topology ( series, hybrid, conventional, split), • Choice of vehicle and component data, • Component choice ( a list of predefined components is available), • Component scaling ( battery, fuel cell system and electric motor), • Choice of control strategies, • Choice of drive cycle, • Parametric studies, • Display of results ( traces of values), • Summery of results. However the graphical user interface did not work in all cases and was therefore only of limited use. Also the use of a graphical user interface limits the flexibility of the program. A fuel cell system model is provided. It has the following characteristics: • The model covers warm up times and penalties associated with the warm up of the system. • Emissions are considered in the model but currently all data for modeling emissions are set to zero. 21 • Transient characteristics of the reformer are modeled with a first order transfer function. The stack characteristics are modeled using a one dimensional steady state lookup table. • The airside and water and thermal management characteristics are only considered through their impact on the overall fuel efficiency and transient effects are not taken into account. • In summery it could be said PSAT provides a fuel cell system placeholder model that mimics the effects of a fuel cell system  instead of a model based on fundamental principles. Strengths of PSAT are: • Availability of a large variety of vehicle concepts • Graphical user interface Weaknesses of PSAT are: • the merge of controls and component models, together with the not strict separation of functionality hurts rapid prototyping as one method of continuous validation • the merge of controls and component models does not allow validation on the component level • the merge of controls and component models lead to difficult to oversee interfaces and potentially problems in program maintenance and modifications 22 • The documentation references mostly to the graphical user interface. However many parts in the actual program are not explained11. 11 At the time of this dissertation the documentation was not finished yet. 24 workspace sum1 wh_ v01 veh_ v01 ptc_ series_ fc_ pos1_ au_ v01 mc_ v01 Disclosure main_ disclosure fd_ v01 fc_ v03 ess_ v01 drv_ v02 curves plot cpl_ v03 clock accelec_ v01 au_ v01 t_ hist info_ tx info_ wh info_ veh info_ ptc info_ mc info_ fd info_ fc info_ ess info_ drv info_ accelec info_ cpl 0 Figure 2 3: PSAT model ( most upper level) for the example of an indirect methanol fuel cell hybrid vehicle. 25 Figure 2 4: Graphical user interface PSAT. 26 2.2.3. The Advisor ( Advanced Vehicle Simulator) Model Advisor has been programmed by National Renewable Research Laboratory ( NREL) and is, after registration, freely available on the Internet ( National Renewable Research Laboratory, 2000). Figure 2 5 shows the most upper level of the Simulink code for the case of an indirect methanol fuel cell vehicle. The program is setup in a backwards approach, e. g. the model is not causal. However according to the Advisor online documentation Advisor labels itself as a hybrid backwards/ forwards approach. This name is confusing because it does not recognize the inherent non causality within the structure of the program, the key element of a backwards facing model as defined by Ricardo Consultants ( Heath, 1996), Southwest Research Institute ( Mc Broom, 1999) and Bengt Jacobson ( Jacobson, 1995) 12. As a consequence of the reverse causality the model is considered to be less physical and less mathematically sound. 13 Advisor is programmed in Matlab/ Simulink. However for special modeling aspects the program has been linked to several program tools. John A. MacBain provides in his paper “ Co Simulation of Advisor and Saber A Solution for Total Vehicle Energy Management Simulation” one example for co simulation of Advisor and Saber ( MacBain, 2000). However due to the reverse causality the employment of this method is limited. Furthermore MacBain describes the application of co simulation as the only solution for simulating the closely coupled mechanical and electrical systems in series hybrid vehicles. This is not true. The UC Davis hydrogen model allows the simulation of 12 Bengt Jacobson did not use the terms forward and backward looking models. Instead he used the terms driver controlled for the causal model and conventional model for the “ unnatural causality”. Important is that causality was his reason to distinguish both approaches. 27 this vehicle type without employing the method of co simulation ( UC Davis, Fuel Cell Modeling Team, 1998). This fundamental misjudgment can be taken as one indicator how confusing the reverse causality of Advisor and other backwards looking programs could be to users. From a practical point of view the reverse causality is one major obstacle that has been already pointed out14. The program compensates this partly with an extensive graphical user interface and a large component library. Because of these features the standard user is not required to look into the details of the model. The good online documentation also provides good support in application questions. However, whenever the model itself needs to be modified the user is required to follow the logic dictated by the reverse causality. This could become more challenging than the physical issues involved with the desired modification. Because of this the model is considered neither flexible nor transparent compared with forward looking models. The reverse causality makes the use of control algorithms for rapid prototyping approaches impossible. Therefore this method of mutual validation of the model is not available to the user. 13 See appendix. 14 See appendix. 28 Figure 2 5: Advisor model of an indirect methanol hybrid fuel cell vehicle wheel and axle < wh> vehicle < veh> gal total fuel used ( gal) power bus < pb> motor/ controller < mc> gearbox < gb> fuel cell control stategy < cs> fuel converter < fc> for fuelcell final drive < fd> exhaust sys < ex> energy storage < ess> drive cycle < cyc> fc_ emis ex_ calc t To Workspace Version & Copyright AND emis HC, CO, NOx, PM ( g/ s) Clock 29 Figure 2 6: Graphical User Interface ( GUI) of Advisor 3.0 0.15 0.15 0.2 0.25 0.25 0.3 0.25 30 According to the online documentation, Advisor provides direct hydrogen, directmethanol and indirect hydrocarbon fuel cell vehicle models. In the current version an indirect methanol system is not available ( August 2000, 3.0). The dynamic interaction among components, such as feedback effects, is limited. Subcomponents of the fuel cell system, such as the fuel reformer, air supply or water and thermal management are only modeled in terms of their impact on the net fuel cell system efficiency. Dynamic effects within the fuel cell system itself, such as reformer and air supply time lags, are not considered. For the case of the indirect hydrocarbon system emissions, are not predicted. Strengths: • The strength of advisor is the detailed graphical user interface ( Figure 2 6) that allows the setup and analysis of a wide range of vehicle configurations. The user can choose between 9 predefined drive train configurations. Each configuration allows the choice between 19 electric motors, 9 batteries and 7 fuel cell systems ( Wipke, 1999 and National Renewable Energy Laboratories, 2000). The mentioned components are scaleable and could be combined in a vehicle. The user interface is intuitive and provides rapid access for the educated user to the capabilities of the model. • Short runtime. Because Advisor is a backwards looking model it runs between 2.6 and 8.0 times faster in standard drive cycles than forward looking models ( Wipke, 1999). Weaknesses: 31 • Documentation helps only very little if the model needs to be modified. • The reverse causality makes it difficult to follow the logic of the model. This is one major obstacle for future improvement and development. • Interaction between fuel cell stack, fuel processor and drive train does not include feedback effects. For example it is assumed that the fuel processor is always able to deliver the by the stack required reformate in time. The effect of a drop in stack voltage because of a supply shortage of reformate gas is not modeled, and consequently the electric motor would not provide less torque because of the voltage drop. The feedback of the various components is essential for the modeling of one major issue of fuel cell system and vehicle analysis  transient behavior. The model allows one to investigate only in a very limited way the impacts of different component configurations, parameter variations and control strategies on transient behavior. • If one component is not able to supply the value required by the previous stage, the operating point of the requesting component is not corrected. If component characteristics vary largely over the operating regime, then ignoring the change of the operating point could impose a large error on the results. An iteration process downstream of the limiting component could potentially solve this problem. However this would significantly complicate the model and is not realized in the current version of Advisor. 32 2.2.4. The UC Davis Hydrogen ( 1998 Version) Model The original direct hydrogen fuel cell vehicle model of University of California, Davis ( UC Davis) was programmed during 1998. It is part of a modeling effort sponsored by a group of industry and public sponsors and is not publicly available. It is essentially based on a previous version of Advisor and follows therefore the same structure of a backwards facing model ( Figure 2 7). From a practical point of view the complications are the same as with the Advisor model and are mainly a direct result of the reverse causality. The program employs also an extensive graphical user interface easing the simulation of the different vehicle configurations ( Figure 2 8). The model is specialized for direct hydrogen fuel cell vehicles in a load following and load leveling configuration. In addition pure battery electric vehicles could be modeled. Similarly to Advisor, the fuel cell system is modeled in non transient form employing steady state polarity plots characterizing the fuel cell stack ( fuel cell system place holder model). In addition to the actual fuel cell model, algorithms have been developed that optimize the interaction between various compressor technologies and the fuel cell stack. The results of this optimization process are then included into the vehicle model. However the combination of fuel cell stack and air supply with the optimization strategy makes it difficult to gain the necessary input data in a laboratory for a specific stack or compressor supplier. A new forward looking direct hydrogen fuel cell vehicle model has succeeded this program in 2000. 33 Strengths: • Short runtime similar to Advisor, • Graphical user interface including features for the automatic report generation. • Attempt for the integration of an optimal compressor operating strategy. The direct hydrogen model of UC Davis is the only model ( discussed in this overview) addressing and discussing the potential energy savings in this area. Weaknesses ( see Advisor): • Reverse causality makes it difficult to follow the logic of the model and is one obstacle for further improvement and development, • No feedback effects between motor and fuel cell system interaction modeled, • No correction of the operating point if one component is unable to meet the request, • Separate program required for the integration of new fuel cell stacks and compressors or the modification of the compressor control strategy (“ config” model). 34 Figure 2 7: UC Davis Hydrogen Fuel Cell Hybrid Vehicle Model m/ sec trip transmission stop simulation at specific SOC road load motor/ controller energy storage clock actual velocity mph Simulation Results SOC last Fuel Cell System 35 Figure 2 8: Graphical User Interface of the Hydrogen Fuel Cell Hybrid Vehicle Model of UC Davis 36 2.2.5. The Simplev ( Simple Electric Vehicle Simulation) Model Idaho National Engineering and Environmental Laboratories ( INEEL) developed Simplev beginning in 1990. Since then several updates have been released. The latest update is Simplev 3.0. However the simulation package has been phased out in 1997. It is programmed applying a backwards method ( Idaho National Engineering and Environmental Laboratory, 1993). This programming approach is physically and mathematically less solid than the forward looking approach15. Simplev does not support the method of co simulation. Because Simplev is programmed in Basic, and the source code had not been made available, it is not possible for the user to expand and modify the initial program package. Because of the reverse causality Simplev does not support rapid prototyping. The required input data are standard vehicle and component parameter and steady state maps for motor efficiency, transmission efficiency etc. All the input data are either available or could be made available using standard methods, such as battery and motor bench tests. The program assists the user with a simple graphical interface. The runtime is very short compared with the other program packages. Simplev is capable of simulating various types of internal combustion engine hybrid and battery electric vehicles. Simplev, in its original form, is not able to simulate fuel cell vehicle concepts. It should be noticed that Simplev was introduced in 1990, and was among the first comprehensive programs modeling vehicles employing electric drive trains. Simplev was phased out by INEEL in 1997. 15 See appendix 37 Strengths: • Runtime Weaknesses: • Backwards approach, • No fuel cell vehicle modeling capabilities, • The electric drive train is not sensitive to voltage, • Not flexible ( Source code not available), • No documentation for version 3.0, • No longer available. 38 2.3. Summary Several vehicle modeling tools have been introduced and compared with each other. The points of comparison have been a list of generic requirements for mathematical modeling stated at the beginning of the chapter and restated in the first seven items in Table 2 5. These criteria define the theoretical potential of the modeling approach. In addition in the second half of Table 2 5 ( items 8 10) the actual realized potential has been compared among the different models. Finally the last row states the public availability in October 2000. The compared models could be classified in two different groups. Hyzem and Psat as forward looking models and Advisor, UC Davis H2 ( 1998 version) and Simplev in the group of backwards looking models. The items 1 5 in Table 2 5 state the theoretical potential of the models to incorporate future developments in an efficient and time saving manner. It can be seen that in this respect the group of causal forward looking models offers a higher potential than the group of non causal backwards looking models. The item Nr. 6 “ ease of use” includes two different aspects. First, the support the user receives through a graphical user interface and a good documentation, and second, the logical structure of the model and how it supports modifications. Table 2 5 shows that none of the models have an advantage regarding the ease of use. However this represents only the current state. Hyzem is valued neutral because it does not support the user with a graphical user interface but has a causal structure easing understanding and modifications. Advisor, UC Davis H2 ( 1998 version) and Simplev are valued neutral because they employ a graphical user interface and a non causal structure. Psat is valued 39 neutral although it offers a graphical user interface and a forward looking structure. The reason is that version 4.0 was still in the development state and the user interface was little flexible and unstable. Because a graphical user interface could easily be added to the causal models, while changing the non causal structure of the backwards looking models is not possible the theoretical potential for a better “ ease of use” for the causal models is estimated to be higher. The availability of input data ( item 7), though important, is not a feature that distinguishes the models. Only the UC Davis Hydrogen model ( 1998 version) has a ( minor) disadvantage in this area because of the combination of stack and air compressor data. 16 Items 8 10 compare more specifically how much of the theoretical potential of each model has actually been realized in the current versions. Again the models could be separated into the causal and non causal types. Item 8 shows the vehicle concepts realized today. The differences shown should not be over interpreted. In principle all vehicle types could be modeled with each model. Most of the differences shown could be explained based on the history of the individual models and their sources of funding, primary objective, etc. However the fact that Advisor does not include an indirect methanol fuel cell vehicle model could be one hint towards the difficulties of incorporating non instantaneous responding systems, such as a methanol steam reformer, into the model. Item 9 compares the possibilities of incorporating dynamic characteristics in each model, on hand of the example of start up issues and fuel processor time constants. 40 Though the incorporation of these features is in principle possible in all models, the required effort for the case of non causal models is much larger. Consequently none of the mentioned features has been realized in this vehicle group. The causal models have a significant advantage over the non causal models. The reason is that the causal structure allows the incorporation of dynamic characteristics without difficulties if the physics of the system are understood. Item 10, the issue of emissions, is not an area in which the models are fundamentally different. All models are in principle able to model emissions. However for models only considering hydrogen as a fuel ( UC Davis, H2) the task of modeling emissions is irrelevant. The applied method of modeling emissions in today’s program versions is quasi static with tables including the emissions depending on the emitters ( anode gas burner, fuel processor) operating point. Finally item 10 compares the availability of the individual models in October 2000. At this time only Advisor was publicly available ( as free download on the Internet). However the Southwest Research Institute and Argonne announced that the PSAT model would be made available at a later time this year. Since October 2000 a beta version of PSAT is already available for researchers in the field of fuel cell vehicle modeling only. From a fundamental point of view none of the above models are satisfying. The investigated models compromise in a number of different areas, such as separation of control algorithms from component models and causality. As a result the models become difficult to understand, non modular ( even if they appear modular on the surface) and difficult to validate. 16 This comparison only considers the vehicle level. However in addition to the UC Davis H2 vehicle model a second model is existing generating the necessary vehicle model input data from standard data 41 Also, because of the number of compromises made, none of the investigated models appears suitable as a teaching instrument in companies or universities. Although this aspect is secondary for a professional use in industry, or in the policy arena, it seems important that long term suitable tools for teaching in the area of fuel cell vehicles are available. Based on this comparison a new fuel cell vehicle model is proposed. Key characteristics of this new model are: • Emphasis on fuel cell vehicles, • Incorporation of hybrid concepts including ultra capacitors, • Causal structure, • Preparation of rapid prototyping, • Incorporation of dynamics aspects, • Modular topology, • Incorporation of the new indirect methanol and indirect hydrocarbon fuel cell system models of UC Davis ( Eggert, 2000, Fuel Cell Modeling Group, 2000), • Incorporation of the new direct hydrogen fuel cell system model ( Cunningham, 2000), • Logical structure. such as compressor maps and stack properties ( config model). 42 Model Requirement HY ZEM PSAT Advisor UC Davis H2 Simplev 1. Theoretical soundness + +    2. Completeness + O O O O 3. Flexibility + O    4. Expanded resolution through cosimulation + + O   5. Validation supported through rapid prototyping + ( current version)  ( 1996 version)     6. Ease of use O O O O O 7. Input Data Available + + +  + 8. Realized fuel cell vehicle models ( 2000) Indirect  Methanol and direct H2 in hybrid and non hybrid Versions, no ultra capacitor designs Only battery hybrid fuel cell Vehicles, no ultra capacitor designs Indirect Gasoline and direct H2 in hybrid and non hybrid versions, no ultra capacitor designs Direct H2 in hybrid and non  hybrid versions, no ultra capacitor designs  9. Dynamic Considerations ( Start up, reformer time constants) + current version  Place holder model  Place holder model  Place holder model  10. Modeling of Emissions + ( maps) +( maps)  Not applicable + ( maps) 11. Availability ( October 2000)  +( free17) + ( free)   Table 2 5: Benchmark ( negative or not possible, O neutral, + good). Not emphasized are: 17 For registered researchers. 43 • The employment of a graphical user interface, • Large component libraries, It is expected that through these key features a new fuel cell vehicle model could be developed with applications in • Academia and government ( in teaching and as a tool for policy analysis), • The vehicle industry ( for the analysis of different concepts), • The component industry ( for product planning and technology comparisons). 44 3. Applied Modeling Methodology 3.1. General Aspects For a realistic and defendable vehicle model, only a physically and mathematically well defined and documented modeling approach is acceptable. Therefore this dissertation work chose a causal forward looking18 modeling approach. For modeling of the control algorithms, an approach emphasizing the strict distinction between the controlled system and the controller controlling the system is proposed. For the modeling of the components, either an approach based on first principles or an approach based on experimental data has been applied. Examples for the first principle approach are the modeling of the mechanical properties of the vehicle ( inertia, friction, rotational inertia) or the modeling of the fuel cell stack. Examples for modeling based on experimental data are the use of efficiency maps for the electric motor and transmission. The decision of which approach to follow depends on: • The availability of experimental data; • The complexity a first principle component model would add to the overall model and the effects on run time ( practicality); • The purpose of the model, e. g. what is the question asked. If the emphasis is towards aggregate vehicle properties, individual component models could eventually be simplified. If the emphasis is on one specific component, modeling 18 See literature review ( Hauer 2000). 45 in greater detail than in the first case might be necessary. Two methods to accomplish this are possible: First, by programming a more complex SIMULINK model, and second by employing a special programming tool for a specific component or characteristic. SIMULINK and the other, specialized, program, e. g. SABER for electric components, would then work together. This method is called co simulation. Although not applied in this work, the modular, forward looking structure of the model supports the method of co simulation. Because of the modular structure of the model, the modeling of each component is not limited to either the choice of a first principle model or an approach based on experimental data. Component models are exchangeable as long as the interfaces are compatible. Therefore the results of a detailed component model could be compared with a simpler one running both in the same overall vehicle model. If the differences between both models are neglect able and the focus of interest is on the vehicle and not the component itself one might decide to use the simpler component model for the benefit of a faster runtime. In addition to the above mentioned method of co simulation, the model structure supports the use of rapid prototyping. In this context, rapid prototyping means the process of developing control algorithms in the software model, which are later transferred into existing hardware. The model supports also the concept of “ hardware in the loop,” allowing the replacement of component descriptions of the software model with hardware. From a modeling point of view, “ rapid prototyping” and “ hardware in the loop,” techniques offer the chance for faster model validation. 46 3.2. Mathematics 3.2.1. Introduction The modeling, based on first principles, is done by applying a standard input/ output approach as described by Leonhard ( Leonhard 1985) and Foellinger ( Foellinger 1985) for time invariant systems with one or multiple inputs x( t) and one or multiple outputs y( t). Mathematical component and hardware descriptions are formulated in the form of ordinary differential equations with the time t as the independent variable. The system description could be given in the form of one or several ordinary differential equations dy/ dt = f( t, x( t), y( t)) for the output function y( t) ( Figure 3 1). Figure 3 1: Time invariant input output system for one input x( t) and one output y( t) and a 1st order differential equation relating output and input function. The input function x( t) could be of any form, including discontinuous functions, e. g. a step function or a pulse. The only limitation is that x( t) has to be defined for the complete time interval of interest [ 0, t]. The output function y( t) is calculated as a function of the input function x( t) applying the system description dy/ dt = f( t, x( t), y( t)). For a physical system no singularities are expected. Therefore y( t) is defined for the whole time interval [ 0, t]. The differential equations describing the system could be either of linear or nonlinear form. The equations describing the system are not limited to first order equations. f( t, x( t), y( t)) dt dy = x( t) y( t) 47 A system description with higher order differential equations is possible. In case that the component model requires a higher order differential equation, e. g. nth order, it can be transformed into a first order system of n differential equations that could be solved easily in SIMULINK ( Mathworks corporation, 2001). The general approach for the transformation of an nth order equation is to substitute the higher order derivatives by introducing new variables. Equation 3 1 shows a nth order differential equation with the input function x( t) and the output function y( t). x( t) system input y( t) system output independent time variable : ( ) , ( ), ( ), ( ) ,..., ( ) , ( ) 1 ( 1) 2 ( ) ( 2) = = = = − − − − t where dt d y t dt d y t dt f t x t y t dy t dt d y t n n n n n n Equation 3 1 To solve Equation 3 1 in SIMULINK, it has to be rewritten into a system of n 1st order differential equations for the n unknown functions y( x, t), y1( x, t) .. yn 1( x, t) ( Equation 3 2). 48 dt y t dy t y t dt y t d y t dt y t d where y t dt dy t y t dt dy t y t dt dy t y t dt dy t g t x t y t y t y t dt dy t n n n n n n n n n ( ) ( ) ... ( ) ( ) ( ) ( ) : ( ) ( ) ( ) ( ) ... ( ) ( ) ( ) ( ) ( ) ( , ( ), ( ), ( ),..., ( )) 1 2 2 2 1 1 1 1 2 1 2 3 1 2 1 2 1 1 = = = = = = = = − − − − − − − − − Equation 3 2 The resulting system in Equation 3 2 can be directly programmed in SIMULINK. Essentially SIMULINK provides the solution not only for the function of interest y( t) but also for the first n 1 derivatives of y, respectively y1 … yn 1. The algorithm to rewrite the n th order differential equation does not require linearity in the original equation. It can also applied if the original equation is of nonlinear form. The order of the system is also not a constraint, although physical systems are seldom of a higher order than two. If the system has more than one input x( t), all inputs have to be considered. The first equation in Equation 3 2 is then a function of all inputs x1, x2 … xm, if m is the number of input variables. 49 If the system has more than one output function y( t), the above method can be applied for each output function. An example of a multi input/ output system is the air supply system in which pressure and flow rate set points are input variables and the actual pressure and flow rates in the stack form the output variables. Start of the simulation ( Initial values): For the numerical solution, initial conditions for the integration of the system have to be considered. For a system of nth order, n initial conditions are required. Initial conditions are the values of y1( t= 0),…, yn( t= 0). They are incorporated in the form of initial values of the integrator blocks in the SIMULINK diagram. The so derived first order system of differential equations could then be solved in SIMULINK. An example of a solution to a 2nd order system in SIMULINK with one input and one output is provided at the end of the chapter. Discontinuities: A discontinuity in this context means that the derivative from the left side is different from the derivative from the right side in ( at least) one point of a function. The function is then discontinuous in this point. An example would be if there is a kink in the function. Discontinuities are common in the control algorithms applied for controlling the various components. They are introduced in the form of saturation blocks, switches, thresholds, and tables, and are necessary to model the applied control algorithm. 50 SIMULINK offers a vast number of functions to ease the incorporation of discontinuities into the model. In an analytical approach, the presence of discontinuities makes it harder to solve the equation because it has to be solved for each continuous interval separately. For the numerical approach applied in this work, the problem of discontinuities is less challenging. The applied method for solving the system is to work with one set of differential equations until the solution reaches a discontinuity. The simulation stops and continues then with a new ( modified) set of equations, taking the old system’s last vector of output values as vector for the initial values for the new system. After this, the simulation proceeds as usual until the next discontinuity arises. Not considered in this model are time discontinuities. Realistically, due to the fact that most of the control algorithms are programmed in the software and run in discrete time steps in microprocessors, all control algorithms have to be modeled in discrete form. However, due to the high processor clock speed in comparison to the system time constants, the impact of time discontinuities is minimal and could be neglected. If the processor clock speed is in the order of magnitude of the inverse of the smallest time constant within the controlled system model, the control algorithm would have to be modeled in a time discrete form ( Leonhard 1990). Applied solving algorithm for solving differential equations: SIMULINK offers several solvers supporting the numerical integration of ordinary differential equations. The solvers provided could be classified as variable step solvers and fixed step solvers. 51 Fixed step solvers do not vary the simulation step size during the simulation. Therefore the step size has to be small enough to capture the most transient intervals of the solution with sufficient enough accuracy. On the other hand, a too small step size slows the simulation down. For the hybrid vehicles modeled in this work, the recommended method is the Euler method ( ODE 1). The use of this algorithm for hybrid cases shortens the execution time significantly. Alternative fixed step solvers, available in SIMULINK, are listed in Table 3 1. Variable step solvers vary the step size depending on the slope of the solution. In intervals with a small slope, the step size is increased, while in areas with steep slope ( rapid change of the solution), the step size is decreased to minimize the computational error. The motivation of the variation in step size is to increase the speed of the simulation. Variable solvers provided by SIMULINK are listed in Table 3 1. Among the variable step solvers the ODE 45 method provides a good compromise between reliability ( how likely is it that the simulation runs to the end) and efficiency ( how fast does the simulation run) for the models discussed in this dissertation. The standard solver applied in this work is the Euler algorithm ( Bronstein 1985) for solving the system of differential equations that form the overall model. Assuming the system that has to be solved is stated in explicit form ( Equation 3 3) with the input function x( t) and the output function y( t) ( Figure 3 1): ( ) f ( x( t), y( t)) dt dy t = Equation 3 3 Applying the standard differentiation formula leads to ( Equation 3 4). 52 step size : ( ) ( ) ( ) ( ( ), ( )) Δ = = Δ = + Δ − t where f x t y t t y t t y t dt dy t Equation 3 4 Solving for y( t+ Δt) results in: y( t + Δt) = y( t) + Δt ⋅ f ( x( t), y( t)) Equation 3 5 The recursive algorithm in Equation 3 5 is named the Euler formula. Starting with an initial value y( t= 0), Equation 3 5 allows the integration of the differential equation stated in Equation 3 3. The step size Δt stays constant in this algorithm. In some cases, especially if the solution has large intervals [ t1, t2] with only little variation, the adjustment of the step size could decrease the overall runtime. In intervals with little variation, the step size is increased, while in areas with large variation ( or high dynamic), the step size is decreased. SIMULINK provides assistance for varying the step size offering variable time step solvers. Essentially, the absolute tolerance ε between two steps and the relative tolerance λ between two steps is calculated. If one or the other exceeds a ( in the user interface adjustable) parameter, the iteration step is repeated with a smaller time step size Δt ( Equation 3 6). For checking the relative step size at locations y( t) close to zero a special “ zero crossing feature” could be activated to avoid difficulties in determining the step size in these situations ( Simulink 2001). 53 relative tolerance absolute tolerance : ( ) ( ) ( ) or ( ) ( ) = = + Δ − ≥ + Δ − ≥ λ where decrease Δt and repeat step then y t if y t t y t y t t y t ε ε λ Equation 3 6 Table 3 1: Fixed and variable time step solvers. Fixed step size solvers Description ode1 ( Euler algorithm) This method provides an efficient and reliable solution for all hybrid cases. The recommended step size is 0.005 sec. Recommended solver for all the models used in this dissertation. ode5, ode4, ode3, ode2 For a detailed description see the Simulink web page ( Simulink 2001). None of the listed solvers could ( significantly) increase the reliability or runtime of the simulation. Variable step size solvers ode45 Based on an explicit Runge Kutta ( 4,5) formula, in general, ode45 is the best solver to apply as a " first try" for most problems. ode23, ode113, ode15s, ode23s, ode23t, ode23tb For a detailed description see the Simulink webpage ( Simulink 2001). Depending on the exact configuration of the model one of the listed solvers might lead to a ( i) more reliable, ( ii) more efficient solution. 54 Runtime: Two different effects determine the run time of the overall vehicle model: • The complexity of the model ( this is the number of blocks forming the model); • The system dynamics ( this is how fast the solution including intermediate values change over time). It appears obvious that the runtime increases with the system complexity. More blocks add essentially more equations to the overall system and more equations means that for every iteration step more computations have to be performed. For fixed computational resources, the runtime increases with increasing complexity. Not so obvious is that the system dynamics can have a much stronger effect on runtime than the increase in complexity has. If a system is highly dynamic ( e. g. if parts of the system are oscillating), in the interval of interest or shows rapid state changes only at certain times the runtime could increase significantly. In either case the reason for the increased runtime is that the simulation step size has to be small enough to capture all transient effects. If the solution shows highly transient behavior only at certain points in time ( e. g. during an acceleration), a variable step solver could reduce the runtime. However, if the solution is transient over the complete interval of interest ( e. g. oscillating), the step size has to be kept small all the time. For this case the number of calculations and therefore the runtime increases independent from the choice of the solver. For the sake of a reasonable runtime and due to the finite computer power ( floating point operations / second), the modeling has be constraint to the dominant time constants within the system. 55 A mixture of large and small time constants with a ratio of largest to smallest time constant of several orders of magnitude slows the simulation significantly down. The smallest time constant is effectively determining the step size and with this the total run time of the simulation. For example, the consideration of the cable inductivity and capacity between the fuel cell system and the electric drive train of a vehicle should be avoided because this time constant is significantly smaller than the mechanical time constants due to rotational inertia of the electric drive train or the vehicle mass. On the other hand, in feedback systems it can be necessary to consider even secondary ( small) time constants to avoid algebraic loops in the modeling process. The presence of algebraic loops in the simulation model can be interpreted as an indicator that the analysis of the system is not detailed enough. A significant aspect of the system has not been captured in the model. 19 In case of the presence of an algebraic loop how an additional time constant could be introduced into the system must be carefully analyzed. For the case that no algebraic loop is present, one must consider if the introduction of additional ( smaller) time constants is necessary to describe the interesting properties of a system or if this just leads to an increase in run time. However, in this model it appears that considering the system determining time constants leads to a system model without any algebraic loops, which captures all dominant effects. 19 This is true for physical systems. It can be said that in nature no algebraic loops exist ( no immediate feedback from a system output to a system input). 56 3.2.2. Example and Transfer into SIMULINK Equation 3 7 describes the horizontal movement of a vehicle with the mass m considering an aerodynamic drag, wheel inertia, tire friction, and an external acceleration Force F ( Gillespie 1992). ( ) ( ) ( ) 0 2 ( ) ( ) ( ) 1 2 2 2 2 2 2 1 2 3 2 + Θ ⋅ − = + ⋅ ⋅ ⋅ ⋅ ⋅ + + ⋅ + ⋅ F t dt d s t dt r cw A ds t dt ds t dt ds t dt m d s t μ μ μ ρ Equation 3 7 Following the conclusions of the previous chapter the above 2nd order nonlinear differential equation can be rewritten into a system of two 1st order differential equations by the method of substitution ( Equation 3 8). ( ) ( ) ( ) 2 ( ) ( ) ( ) 0 ( ) ( ) ( ) 1 2 2 2 1 2 3 v t dt ds t F t dt dv t r v t v t cw A v t dt m dv t = ⋅ + μ + μ ⋅ + μ ⋅ + ⋅ ⋅ ρ ⋅ ⋅ + Θ ⋅ − = Equation 3 8 Rearranging Equation 3 8 results in: [( ) ] ( ) ( ) 2 ( ) ( ) 1 ( ) ( ) 2 ( ) 1 2 1 2 3 2 v t dt ds t F t v t v t cw A v t dt m dv t r = ⋅ − + ⋅ + ⋅ + ⋅ ⋅ ⋅ ⋅ + = Θ μ μ μ ρ Equation 3 9 In Equation 3 9 s( t) has the meaning of the distance traveled from t= 0 until t and v( t) is the vehicle velocity at the time t. Because the system of differential equations has two unknown functions v( t) and s( t), two initial conditions have to be considered. These are the vehicle velocity at the beginning of the experiment ( or simulation) v( t= 0) = v0 and 57 the location of the vehicle at the beginning of the experiment s( t= 0)= s0. Equation 3 9 can be seen as the description for an input / output system. System input is the acceleration force F( t) and system outputs are the vehicle velocity v( t) and the vehicle location s( t). Together with the above mentioned starting conditions, the system can be easily solved in SIMULINK for all input traces F( t). Figure 3 2 shows the graphical representation of the SIMULINK algorithm. ∫ 2 1 r m+ Θ 2 ⋅ cw ⋅ ρ ⋅ A 1 F( t) ∫ v( t) s( t) x2 x2  +    μ1 μ2 μ3 Figure 3 2: Graphical representation of Equation 3 9. The initial conditions s( t= 0)= s0 and v( t= 0)= v0 are equivalent to the integrator status at t= 0. Therefore the initial conditions can be directly programmed into the SIMULINK representation. 58 4. Model Description 4.1. Modeling Structure and Goals This chapter explains the setup of the fuel cell vehicle model. The model is developed using a forward looking approach ( Hauer 2000). The model description starts with the most upper level, the vehicle. This level illustrates how the driver is interacting with the vehicle and how the drive cycle is fed into the model. After the establishment of this overall modeling frame, the models for all major components are explained in the chapter “ Component models.” The component models interface with each other and form, together with the vehicle properties, the overall vehicle model. One individual component could also consist of several subcomponents. One important characteristic of this model is that the component interfaces transfer only physical properties from one component to the other components. The limitation to “ physical“ interfaces qualifies the model for the use in rapid prototyping experiments. It also benefits the understanding and eases maintenance and further development because the model could be more easily associated with an image of the physical reality of the vehicle. Because of the strict modularity, individual component models could be tested off line or replaced with a different model for the same component if the interfaces of the replacement model match the interfaces of the model replaced. Besides the component models, the control strategies for the interaction of the individual components determine the overall vehicle characteristics. These control strategies are also explained under the headline “ Component models.” An example for a control strategy in a non hybrid vehicle is the control algorithm for the fuel processor. An example for a control strategy in a battery hybrid vehicle is the activation of the fuel cell 59 system depending on the motor power and/ or the state of charge of the battery and/ or other parameters. The modeling effort pursues two objectives: First to estimate fuel consumption, energy flows and losses, and the vehicle dynamics ( acceleration time and top speed) for different vehicle configurations ( parameters) and different vehicle types ( hybrid, non hybrid vehicles). Second the safe and fast investigation and development of control strategies for the exploration of theoretical limits and the use in existing hardware later. 60 4.2. Vehicle Model The uppermost level of the fuel cell vehicle model consists of the main blocks “ Specified Drive Cycle”, “ Driver” and “ Vehicle" ( Figure 4 1). Figure 4 1: Uppermost level of the indirect methanol fuel cell vehicle model. Driver Vehicle Specified Drive Cycle Vehicle velocity Brake pedal position Acceleration pedal position 61 4.2.1. Drive Cycles and Driver Model This chapter discusses the drive cycles available in the model and the algorithm that compares these drive cycles with the actual vehicle velocity and adjusts the acceleration and brake pedal position. The block “ Specified Drive Cycle” describes the demanded driving profile by specifying the velocity over the time. Standard drive cycles available in this simulation tool are the drive cycles listed in Table 4 1. Available Drive Cycles Length / Time Max. speed / Avg. speed Max. accel. Avg. accel. Federal Urban Driving Schedule ( FUDS) 7.45 mi / 1369 sec 56.7 mi/ h / 19.6 mi/ h 1.48 m/ sec2 0.34 m/ sec2 Federal Highway Cycle 10.26 mi / 765 sec 59.9 mi/ h / 49.2 mi/ h 1.43 m/ sec2 0.13 m/ sec2 US O6 Cycle 8.01 mi / 600 sec 80.3 mi/ h 48 mi/ h 3.75 m/ sec2 0.45 m/ sec2 ECE Cycle 0.62 mi / 195 sec 31.1 mi/ h 11.4 mi/ h 1.05 m/ sec2 0.43 m/ sec2 MVEG Cycle 6.79 / 1220 sec 74.6 mi/ h 20.03 mi/ h 1.05 m/ sec2 0.37 m/ sec2 EUDC 90 6.58 mi / 1220 sec 55.9 mi/ h 19.4 mi/ h 1.05 m/ sec2 0.39 m/ sec2 EUDC 120 4.32 mi / 400 sec 74.6 mi/ h 38.9 mi/ h 0.83 m/ sec2 0.26 m/ sec2 Japanese 10 15 cycle 2.59 mi 660 sec 43.5 mi/ h 14.1 mi/ h 0.79 m/ sec2 0.39 m/ sec2 Table 4 1: Available standard driving cycles with their main characteristics. The block “ driver” represents the driver properties and driver characteristics. The main task is the comparison of the velocity specified in the driving cycle with the actual vehicle velocity. In case the actual vehicle velocity is below the vehicle velocity specified in the drive cycle the driver sends an acceleration command to the vehicle block. In case the vehicle velocity is above the specified velocity the driver sends a brake command to 62 the vehicle block. In a real vehicle, the acceleration signal and the brake signal represent the position of the acceleration pedal and brake pedal. From a systems point of view the driver can be seen as a controller for the “ system” vehicle. The inputs for the “ system” vehicle are the acceleration and brake commands and the system output is the vehicle velocity. Although the presence of a driver model is important for the setup of the simulation, this analysis will not focus on the block " driver." The only criteria this block has to meet is to ensure that the vehicle follows the drive cycle as closely as possible whenever physically possible. In this respect the block " driver" has the same task as a driver on an emissions bench, namely following a given drive cycle. The complete driver model is shown in Figure 4 2. Drive cycle Td  + Ti  + Tr >= 0 <= 0 proportional integral predicting the future delay vehicle velocity k1 k3 1/ Ti + + + reaction time acceleration request brake request y1 y2 y3 y4 Figure 4 2: Driver model. The model inputs are the specified drive cycle and the vehicle velocity. The model outputs are the normalized ( between 0 and 1) acceleration request and the normalized ( between 0 and – 1) brake request. The following steps are taken to calculate the output values in dependence of the input values. The ( actual) vehicle velocity is subtracted from the ( delayed) drive cycle 63 request. The difference between both values is fed into a proportional integral controller ( PI controller). The proportional part is calculated according to Equation 4 1. ( ) time [ sec] time is the time the driver looks into the future [ sec] drive cycle velocity [ km/ h] vehicle velocity [ km/ h] proportion al factor of the PI algorithm [ 1/ km h ] : y ( ) ( ) ( )  1 1 1 1 = = = = = ⋅ = ⋅ − − t T v ( t) v( t) k where t k v t v t T d cycle cycle d Equation 4 1 The integral part of this PI controller is realized using an integral algorithm with a build in anti windup feature ( Figure 4 3). The reason is to avoid the windup of the integrator to very high values in cases the vehicle is physically not able to meet the drive cycle, e. g. in an acceleration experiment). Equation 4 2 describes the algorithm of the integrator with anti windup function. y ( ) output of the integrator with anti  windup [ 1] y ( ) intermediate value [ 1] c feedback constant [ km/ h] integration constant [ h/ km] : ( ) 1 ( ) ( ) ( ( )) 2 2 1 0 2 1 2 2 = ′ = = = ⋅ ′ = ⋅ − − + ⋅ − ′ ∫ t t T where v t v t T c y y t dt T y t i t cycle d i Equation 4 2 The final output of the integrator with anti windup is stated in Equation 4 3. upper and lower bound for y [ 1] : ( ) if ( ) ( ) ( ) if ( ) 2 2 2 2 2 2 2 2 2 2 = = ′ ≥ = ′ ′ < y where y t y y t y y t y t y t y Equation 4 3 64 Ti ++  + input ideal integrator limiter c1 y2’ y2 Figure 4 3: Integrator with “ anti windup function”. In addition to the PI algorithm, a third component impacting the driver request can be added ( Equation 4 4). This third component takes into account that on an actual roller test stand the driver is able to foresee the future drive cycle. 20 This knowledge about the future can improve the driver’s decision and allows a more accurate following of the drive cycle. The value the driver pays to the future is taken into account by a gain block. A gain of zero would mean that the driver does not pay any attention to the future at all. With increasing gain his attention increases. The delay determines how far the driver looks into the future. A delay of zero would be equivalent to a time horizon of zero seconds. If the delay time increases, the driver’s time horizon increases. 20 In a roller test stand the drive cycle request is communicated on a screen. This screen does not only show the current velocity request in digital form. Instead, the drive cycle, including the next few seconds of the drive cycle together with the actual vehicle speed, is displayed in the form of speed traces. Therefore, the driver is able to take the future velocity requests into account and base his current decisions on this additional knowledge. The net effect is that the driver can follow the drive cycle more accurately. 65 ( ) ( ) intermediate value [ 1] constant for how the driver values the future [ h/ km] : ( ) ( ) ( ) 3 3 3 3 = = = ⋅ − − y t k where y t k v t v t T cycle cycle d Equation 4 4 All three intermediate values y1, y2, and y3 are summed and filtered through a low pass filter in the form of a first order transfer function ( Equation 4 5). y ( ) intermediate value [ 1] filter time constant [ sec] : ( ) ( ) ( ) ( ) ( ) 4 4 1 2 3 4 = = ⋅ + = + + t T where y t y t y t y t dt T dy t r r Equation 4 5 Finally, the filtered value is limited to values between  1 and 1, which are then interpreted as the driver’s request for more or less acceleration. According to Equation 4 6, positive values are interpreted as a request for acceleration. Negative values are interpreted as a request for deceleration ( braking). brake_ request driver request for deceleration ( braking) [ 1] acc_ request driver request for acceleration [ 1] where : 0 if y ( t) 0 1 if y ( t)  1 if  1 y ( t) 0 0 if y ( t) 0 1 if y ( t) 1 if 0 y ( t) 1 4 4 4 4 4 4 4 4 = = = > = − < = ≤ ≤ = < = > = ≤ ≤ brake_ request brake_ request brake_ request y ( t) acc_ request acc_ request acc_ request y ( t) Equation 4 6 66 4.2.2. Physical Vehicle Model In the previous chapter, the driver model and how the driver controls the actual vehicle velocity were discussed. In this chapter, the model for the vehicle and its main components and component arrangements will be explained. The block “ vehicle” in Figure 4 4 contains the four sub blocks “ Drive Train,” “ Vehicle Curb,” “ Power Source,” and “ Vehicle Controls” ( Figure 4 4). The inputs of this block are the brake pedal position and the acceleration pedal position. Both are derived in the previous chapter. The model output is the actual vehicle velocity. The acceleration pedal position feeds into the block " Drive Train" and determines the fraction of the maximum motor torque available supplied to the vehicle wheels. The brake pedal position feeds into the block “ Vehicle Controls.” This block separates regenerative braking ( in hybrid vehicles only) and mechanical braking. The request for regenerative braking is fed to the block “ Electric Motor” and the request for mechanical braking is fed directly to the block “ Vehicle Curb.” Drive Train Vehicle Curb Power Source current torque motor speed voltage acc. pedal position brake pedal position Vehicle Controls velocity Figure 4 4: Content of the block " Vehicle". 67 The block “ Drive Train” includes models for the power electronics for the electric motor, the electric motor itself, controls for the electric motor, and the transmission. Depending on the driver request, expressed by the acceleration pedal position and brake pedal position, the block “ Drive Train” provides torque to the wheels and draws current from the power source ( battery, ultra capacitor, or fuel cell stack). The block “ Vehicle Curb” models the mechanical properties of the vehicle curb such as aerodynamic drag, rolling resistance, mass, etc.. The inputs into this block are the applied wheel torque and the signal for the mechanical brake fraction. The outputs are the vehicle velocity and the motor speed. In designs not considering tire slip and a one speed transmission, both values are directly correlated with each other. The block “ Power Source” could include models for a fuel cell system, a battery system, an ultra capacitor system, or a combination of all three systems. The input of this block is the electric current drawn by the motor. The output is the voltage seen by the dc terminals of the power electronics for the electric motor. For the case of a non hybrid fuel cell vehicle this is the same voltage as the fuel cell stack voltage. In hybrid designs, this voltage could be the battery voltage or any other voltage depending on the exact design. The overall design of the vehicle model incorporates two major feedback loops motivated by the dependence of the maximum motor torque of the electric drive train on the voltage supply and the motor speed. As soon as the driver signals a torque request the electric drive train starts providing torque to the wheels. Because of this torque supply, the vehicle accelerates and the motor speed increases. This increase in motor speed feeds back to the block “ Drive Train” because of the sensitivity of the motor torque to 68 fluctuations of motor speed. This feedback loop represents the feedback on the mechanical side of the vehicle. As soon as the motor starts spinning, it provides mechanical power to the wheels. It can only do this by drawing electrical power from the block “ Power Source.” As a result, the motor draws an electric current from the power source. Due to the internal resistance21 of the power source, the voltage at the motor terminals drops depending on the load current drawn. Because of the sensitivity of the maximum motor torque on the supply voltage, the drop in voltage feeds back to the electric drive train. This feedback loop represents the feedback effects on the electrical side. Mechanical and electrical feedback together determine the overall characteristics of the combined system drive train, power source, and vehicle curb, which form the overall vehicle model. This setup of the vehicle is close to the setup of a physical vehicle. The only interface22 between the drive train and the source of electric power is the electric connection between both components. This interface can be fully described by change of voltage and current over time. On the mechanical side, the interfacing variables between the drive train and the vehicle curb are the wheel torque and the wheel speed. Similar to the electric side, the interface can be fully described by providing both values in time. Properties of the vehicle and the vehicle environment The overall vehicle is modeled according to the force balance stated in Equation 4 7. This equation accounts for the aerodynamic drag force; the friction force due to the rolling resistance of the tires; the vehicle inertia including rotational inertia of tires, motor, and transmission; and the climbing force necessary to climb a hill. The sum of all 21 The internal resistance could vary over time. 69 these forces is the force required to operate the vehicle (“ motor” force and friction brake force). motor brake friction drag inertia c b F F F F F F lim + = + + + Equation 4 7 The individual forces can be expressed according to Equation 4 8 to Equation 4 13. Solving Equation 4 7 to 4 13 for the vehicle velocity and then integrating yields an equation for the vehicle velocity v. The force necessary to accelerate or decelerate the vehicle is the force applied to the vehicle by the electric motor plus the braking force due to the mechanical brakes of the vehicle ( left side of Equation 4 7). The applied motor torque is converted to a linear acceleration force accessing the vehicle. The same has been done for the brake force; although in reality this brake force is applied to the wheels, the model assumes a linear braking force that decelerates the vehicle directly ( Equation 4 8). Maximum braking force [ N] Driver request for braking [ 1] Wheel torque introduced by the motor [ Nm] Wheel radius [ m] Force induced by the friction brakes [ N] Force induced by the electric motor [ N] : max max = = = = = = + = + ⋅ brake wheel wheel brake motor brake wheel wheel motor brake F q T r F F where q F r F F T Equation 4 8 The friction term represents the friction due to tire resistance and friction in the wheel bearings ( Equation 4 9). 22 Except information flow. 70 vehicle velocity [ m/ sec] friction coefficient increasing with the square of the velocity [ m sec ] friction coefficient increasing linear with velocity [ m sec] friction coefficient independant of velocity [ 1] gravity [ m sec ] vehicle mass [ kg] : ( )  2 2 2  1 1  2 2 1 2 = = ⋅ = ⋅ = = ⋅ = = ⋅ ⋅ + ⋅ + ⋅ v g m where F m g v v friction μ μ μ μ μ μ Equation 4 9 The aerodynamic drag is considered according to Equation 4 10. frontal area[ m ] coefficient of drag [ 1] density of air [ kg m ] : 2 1 2  3 2 = = = ⋅ = ⋅ ⋅ ⋅ ⋅ A c where F c A v w drag w ρ ρ Equation 4 10 The force necessary to overcome the vehicle inertia is the sum of the force necessary for accelerating the vehicle mass plus the force necessary for the acceleration of the rotational inertia of the wheels. Wheel speed in [ rad/ sec] Wheel inertia [ kg m ] : 2 = Θ = ⋅ ⋅ Θ = ⋅ + wheel wheel wheel wheel wheel inertia where dt d dt r F m dv ω ω Equation 4 11 The wheel speed and the vehicle velocity are related to each other according to Equation 4 12. This equation assumes that the tires won't slip. In case of tire slip, this Equation has to be modified. wheel wheel r ω = v Equation 4 12 71 Finally, the climbing resistance ( the force required to go uphill or the force gained going downhill) is considered in this model. grade the vehicle needs to overcome [%] : sin tan 1 100 lim = = ⋅ ⋅ − grade where F m g grade c b Equation 4 13 The sum of all forces impacting the vehicle determines, together with the vehicle mass, the vehicle acceleration. Equations 4 7 to 4 13 are used to calculate the vehicle acceleration as a function of time. The integration of the vehicle acceleration results in the vehicle velocity. The required starting value at t= 0 sec represents the vehicle velocity at t= 0 sec. This initial velocity is set to 0 km/ h. Equation 4 14 shows the algorithm for the calculation of the vehicle velocity. Figure 4 5 is the graphical representation in form of a Simulink diagram of this algorithm. The vehicle velocity can be calculated for a given wheel torque. The wheel torque itself depends on the vehicle velocity and is calculated in the block " motor." Because of the non linear relationship between the provided wheel torque and the vehicle velocity, Equation 3 14 cannot be solved explicitly. The braking force Fbrake_ max in Equation 4 14 is less than or equal to zero. 72 q F m g v v grade c A v dt r T r m v t t t brake w wheel wheel wheel wheel ⋅ ⋅ ⋅ ⋅ ⋅ − ⋅ + ⋅ − ⋅ ⋅ + ⋅ + ⋅ + + Θ = ∫= − 0 2 1 2 _ max 1 2 2 2 1 100 sin tan ( ) 1 μ μ μ ρ Equation 4 14 2 velocity km/ h 1 wheel speed rad/ sec  Kwheel radius  Kwheel inertia  Kvelocity m/ sec in wheel speed [ rad/ sec] 3.6 velocity from m/ sec to km/ h velocity friction force in N friction force1 v elocity f orce in N climbing force force in velocity force out avoid negative velocity v elocity drag f orce in N aero drag Sum resulting wheel torque [ Nm] mechanical brake f orce resulting acc. f orce [ N] wheel speed velocity Results 1/ s Integrator 2 wheel torque Nm 1 braking force N Figure 4 5: Simulink representation of the mechanical vehicle properties. 73 4.3. Component Models 4.3.1. Electric Motor Including Power Electronic Many different motor technologies for electric vehicle drive trains are in use today. Among them are induction motors, permanent magnet brushless dc motors, dccurrent motors, and switched reluctance motors ( Nahmer 1996, Skudelny 1993). Two different modeling philosophies are applied in today’s vehicle models for the modeling of the electric drive train and the power electronics. The first approach is based on fundamental physical principles. Motor torque and speed are calculated based on armature current and field current ( armature current and magnetic field for permanent magnet motors). This approach requires a detailed motor model for each motor technology. A motor model for an induction motor would be fundamentally different from a motor model for a brushless dc motor. The input parameters for this approach are the motor geometry, material parameters, and the electrical parameters of the motor coil and power electronics. Li and Mellor ( Li and Mellor 1999) describe such a modeling approach for the case of a brushless dc motor. 23 The other possible modeling approach is based on static maps for the drive train efficiency in dependence of the motor torque and speed and the maximum motor torque in dependence of the speed and applied voltage. This second approach is followed by Ricardo Consultants ( Heath 1996) and National Renewable Energy Laboratories ( NREL, 1999). This modeling approach is technology independent, e. g. the same model could be used for different motor technologies. Only the motor describing parameters, such as maximum motor torque and maximum motor speed and the above mentioned maps have 23 In the paper, the brushless dc motor is referenced as a brushless ac motor . 74 to be adjusted for each specific motor technology and motor configuration ( size, characteristic). The necessary input data for this approach could be gained on a motor test stand similar to the one described by Nahmer ( Nahmer 1996). For gaining the efficiency map, the motor is operated at one specific operating point ( torque and speed) and the electrical input power is measured. The efficiency is the ratio of mechanical output power over electrical input power. For gaining the map of maximum torque in dependence of speed and voltage, the motor is operated at one operating point ( speed, voltage) and the maximum motor torque the motor is able to deliver is measured ( increase of the mechanical load until the motor speed drops while holding the terminal voltage constant). Due to the significantly shorter runtime and better availability of the necessary input data, the second modeling approach with static maps has been chosen in this dissertation. For modeling of the motor transient characteristics, the static approach has been modified and incorporates the mechanical time constant implied by the motor inertia. This time constant is the dominant time constant and exceeds the electrical time constant due to the coil inductivity and resistance, by far which is on the order of microseconds ( Nahmer 1996). The modeling based on static maps allows also the incorporation of all currently applied motor technologies without changing the model structure. Interface: On the electrical side the motor model including power electronics interfaces with the dc power source ( battery system, fuel cell stack, or ultra capacitor system). The variables at this interface are the dc current and the dc voltage. On the mechanical side the motor shaft interfaces with the transmission. Interfacing variables are the shaft torque 75 and the shaft speed ( Figure 4 6). On the information side ( data bus) the motor receives the brake pedal position ( only for hybrid vehicle designs with electrical energy storage) and the acceleration pedal position. However, if the motor controller is excluded from the actual motor, as shown in Figure 4 6, the motor receives a signal for the requested motor torque from the motor control algorithm. brake pedal position acc. pedal position dc bus voltage motor speed  + xx// efficiency map maximum motor torque dc drive train current net motor torque motor control algorithm inner torque motor η dt Θ⋅ dω Figure 4 6: Structure of the motor block including power electronics and motor control algorithms. The characteristics of the motor and the power electronics are inside the by the dashed line marked area. Outside of this area is the motor control algorithm that takes the inputs shown and derives a signal for the requested motor torque. Parameters: For steady state operation, the motor including the power electronics is modeled with a two dimensional efficiency map ( Figure 4 7). This map shows the overall motor and drive train efficiency as a function of motor speed and motor torque for steady state conditions. The influence of voltage fluctuation on the peak efficiency and shape of the islands of constant efficiency is minor and can be neglected ( Nahmer 1996). However, if 76 the motor is operated at lower voltages, not all operating points shown on the map are valid operating points. With decreasing voltage, the operating regime shrinks to the area within the lines of maximum torque shown in the Figure 4 8. Figure 4 8 shows a map for the maximum motor torque as a function of motor speed and terminal voltage. Both maps are derived from experiments for the case of a 75 kW induction motor. The efficiency map includes the power electronics. Therefore the maps represent not only the motor properties but also the properties of the combined system of power electronic and electric motor including control algorithm, such as torque limitation at lower voltages. 0 2000 4000 6000 8000 10000 12000  300  200  100 0 100 200 300 Motor speed [ rpm] Motor torque [ Nm] 0.92 0.92 0.8 0.85 0.88 0.9 0.91 0.92 0.92 0.91 0.9 0.88 0.85 0.8 0.7 0.5 0.7 0.5 Motor Mode Generator Mode Figure 4 7: Motor efficiency map. 77 0 1000  300 2000 3000 4000 5000 6000 7000 8000 9000 10000  200  100 0 100 200 300 200 V 400 V 250 V 300 V 350 V 200 V 250 V 300 V 350 V 400 V Motor Mode Generator Mode Motor torque [ Nm] Motor speed [ rpm] 3000 Figure 4 8: Map of maximum torque. Besides the maps shown in Figure 4 7 and Figure 4 8, the only other parameters that characterize the electric motor including the power electronics are the rotational motor inertia and the motor mass. The motor inertia determines mechanical transients of the motor, e. g. the motor acceleration if no mechanical load is applied, and the motor mass influences the overall vehicle mass and with this the vehicle acceleration for a given configuration. Algorithms: For modeling purposes only the upper half ( 1st and 2nd quadrant) of both maps has been measured ( acceleration mode). The lower half ( regenerative braking) has been derived by mirroring the upper half. Because of friction within the motor bearings and frictional losses due to the aerodynamic drag ( rotor) this assumption is not 100% correct. While in the acceleration mode the frictional losses reduce the available net motor shaft 78 torque, in the regenerative braking mode the frictional losses would provide additional shaft torque ( Figure 4 9 and Figure 4 10). Only if the mechanical frictional losses could be neglected would the mirroring technique provide exact results. However, if the motor is not cooled by forced air through a fan sitting on the motor shaft, the frictional losses are much smaller than the provided net power. For this case the mirroring technique is justified and the maximum torque in the generator mode equals the maximum motor torque for the same speed and terminal voltage. electric motor electric power electrical losses mechanical losses ( friction in bearings and aerodynamic drag) net shaft power Figure 4 9: Power flow and losses in acceleration mode. 79 electrical losses electric motor electric power mechanical losses ( friction in bearings and aerodynamic drag) net shaft power Figure 4 10: Power flow and losses in regenerative braking mode. The motor efficiency during acceleration phases is stated in Equation 4 15. electrical power ( dc)[ W] accessable net mechanical power [ W] motor efficiency in acceleration mode [ 1] : _ motor _ motor = = = = el mech net el mech net P P where P P η η Equation 4 15 During phases of regenerative braking the motor efficiency is stated in Equation 4 16. motor efficiency in regenerative brake mode [ 1] : regen _ regen = = η η where P P mech net el Equation 4 16 The discussion above assumed the steady state operation of the electric motor. For the transient case, the motor inertia has to be considered ( Equation 4 17). The usable motor torque supplied to the transmission is the motor shaft torque generated by the motor minus the product of motor inertia and angular shaft acceleration. During phases of vehicle acceleration, the torque supplied to the wheels is reduced and less torque is available for the acceleration of the vehicle. During phases of deceleration, the motor 80 inertia effectively acts as an energy storage that has to be discharged for the deceleration of the vehicle. The stored energy has to be dissipated in the brake system or converted into electrical energy if the vehicle concept allows for regenerative braking. Motor shaft speed [ rad/ sec] Motor shaft torque [ Nm] Motor inertia [ kg m ] Torque supplied to the transmission[ Nm] : 2 = = Θ = ⋅ = = − Θ ⋅ motor motor motor trans motor trans motor motor T T where dt T T d ω ω Equation 4 17 The torque supplied by the motor to the transmission depends on the request of the motor control algorithm multiplied by the maximum torque the motor is able to provide ( Figure 4 8). It is stated in Equation 4 18. The request of the motor control algorithm is derived from the inputs to this algorithm such as driver request and torque reduction due to high or to low voltage. The motor controller and the embedded control algorithms are described in the next chapter. Bus voltage [ V] Torque request motor controller [ 1] voltage and speed [ Nm] ( , ) Max. motor torque at this specific : ( , ) _ max _ max = = = = ⋅ dc motor dc motor motor motor dc motor V p T V where T T V p ω ω Equation 4 18 On the electrical side of the motor, the dc motor current is derived by balancing mechanical power at the motor shaft and electric power at the motor terminals. The motor torque times the motor speed is equal to the product of drive train voltage times drive 81 train current times motor efficiency. Solving this power balance results in Equation 4 19 for the drive train current on the dc side of the power electronics if the motor is in acceleration mode. Motor efficiency [ 1] Dc current into drivetrain [ A] : ( ) ( , ) _ , _ = = ⋅ ⋅ = motor motor dc dc motor motor motor motor motor dc motor motor dc I where V T I T V η η ω ω ω Equation 4 19 The motor efficiency in Equation 4 19 is taken from the motor efficiency map in Figure 4 7 for positive torque and positive speed ( 1st quadrant). For the case of regenerative braking in hybrid vehicle designs, Equation 4 19 changes to Equation 4 20. Motor efficiency in the mode of regenerative braking [ 1] : ( ) ( , ) , _ = ⋅ ⋅ = regen dc regen motor motor motor motor dc motor motor dc where V T I T V η η ω ω ω Equation 4 20 The motor efficiency in Equation 3 20 is taken from the motor efficiency map in Figure 4 7 for negative torque and positive speed ( 4th quadrant). 82 4.3.2. Motor Controller and Motor Control Algorithm According to the modeling philosophy, the control algorithms are separated from the component descriptions. This principle is also followed through for the electric drive train. The distinction allows greater flexibility and the use of advanced techniques such as rapid prototyping. The motor control algorithm determines how the acceleration pedal position and the brake pedal position inputs determine the state of the electric motor, e. g. how much torque is requested. In addition to this “ basic” functionality a number of safety and convenience features could be programmed and their impact on the vehicle characteristics tested. Generally, the algorithms could be either programmed in the vehicle controller or in the motor controller. From a pure modeling point of view the difference is not significant. However, in real vehicles, in some cases the supplier situation might require that “ know how” be kept outside of the motor controller. If this is the case, specific motor control algorithms could be realized in the vehicle controller. In this work, it has been decided to place all motor related control algorithms into the motor controller. Figure 4 11 shows the graphical representation of the algorithm. The overall algorithm splits up into two parts. The first part is responsible for the operation of the electric drive system in the motor mode. The second part is responsible for the operation of the electric drive system in the generator mode. The latter one is only active in hybrid configurations that allow for the regeneration of mechanical power during braking. 83 In the motor mode the relevant input variables are the motor speed, the motor temperature ( or the temperature of the cooling system), the voltage at the dc side of the power electronics, and the acceleration pedal position. In the generator mode the relevant input variables are the terminal voltage at the dc side of the power electronics, the motor speed, the motor temperature, and the brake signal indicating the request for regenerative braking. In the motor mode the normalized acceleration pedal position requests the fraction of the peak motor torque available. This peak motor torque is a motor constant and is the maximum torque the drive train is able to provide at zero speed and maximum dc voltage at the dc side of the power electronics. This, by the driver requested torque value, can be reduced by several factors: • If the motor speed is too high, e. g. in downhill situations, the motor centrifugal forces accessing the rotor increase and this increase could potentially damage the rotor. Therefore it is necessary to limit the accelerating motor torque beyond a maximum speed but below the critical motor speed that causes damage to the motor. • If the motor temperature is too high, e. g. the losses in the electric motor led to an increase in the motor temperature above the critical temperature. • If the supply voltage is too low. This function is not for the protection of the electric motor but for the protection of the power source ( fuel cell stack, battery or ultracapacitor). A too low voltage increases the possibility of cell reversal and with this a potential damage at the supply side. 84 In the generator mode the normalized electric brake signal derived from the normalized brake pedal position24 determines the fraction of the maximum torque the motor is able to provide in the generator mode. This peak generator torque is the peak torque the drive train is able to provide in the generator mode at zero speed and maximum voltage. It is approximately the same torque as the maximum motor torque but with the opposite sign. Just as in the motor mode, in the generator mode the requested torque could be reduced and increased by several factors: • if the voltage at the dc terminals of the power electronics is too high the generator torque and with this the recharged power needs to be decreased. This functionality protects the battery or ultra capacitor storage from overcharging. • if the temperature of the drive train or the associated cooling system is too high the torque in the generator mode needs to be reduced to avoid damage • if the motor speed is too high, e. g. in downhill situations, the increasing centrifugal forces could destroy the electric drive train. To protect the drive train the generator torque could be increased if the energy storage could accept the additional power. The derived acceleration torque request ( in the motor mode) or the brake torque request for the braking mode is then compared to the actual torque the drive train provides. The result of this comparison is fed into a Proportional – Integral controller ( PI – controller). The output of this controller is limited to upper and lower boundaries and filtered through a first order transfer function, which represents low pass characteristics of the control algorithm to avoid the impact of noise. Finally, the result of this algorithm 24 See chapter “ Vehicle controller.” 85 is the output of the motor controller and determines how much of the motor torque available is requested. An additional function, not realized yet but possible to add, is the mimic of the compression torque of an IC engine vehicle. Because of the fact that electric drive trains have very few frictional losses, the idle characteristics of electric vehicles and IC engine vehicles are different. IC engine vehicles decelerate if the acceleration pedal is released due to significant air compression losses in the engine. In contrast, electric vehicles don’t show this deceleration because no compression losses are present and other frictional losses are small compared to the compression losses. Thus, for the driver of electric vehicles, unfamiliar behavior might lead to driver decisions less optimal for the overall energy consumption of the vehicle. If the driver sees an obstacle, e. g. a red light, he releases the acceleration pedal. However, the vehicle decelerates at a much slower rate than he is used to in IC engine vehicles. It is therefore possible that he approaches the obstacle faster than he thought and is forced to perform a rapid ( last minute) braking maneuver to avoid a collision. In this rapid braking maneuver most of the kinetic energy stored in the vehicle mass is dissipated into heat in the friction brakes and not recovered by generatoric braking. The overall energy balance would be more optimal if the driver had decided to start a gentle braking maneuver as early as possible and recovered the maximum of the kinetic energy stored in the vehicle with generatoric braking. However, this driver behavior is unlikely because it is different from the conventional vehicles. For driver assistance, a function that automatically switches the drive train into the generator mode if the acceleration pedal is released could be implemented. In this case, the 86 requested brake torque simulates the compression losses of an IC engine vehicle. The torque could be constant and speed independent or varying with vehicle speed. motor ( speed to high) max. brake torque XXXX voltage ( to low) 1 Tp+ 1 proportionalintegral controller saturation filter +  actual motor torque acc. signal brake signal XXXXX + + voltage ( to high) max. acc. torque temperature motor speed ( to high) requested torque + + + y y1 yout Figure 4 11: Motor control algorithm. Equations 4 21 to 4 26 show the motor control algorithm illustrated in Figure 4 11 in mathematical form. During regenerative braking the requested torque is computed according to Equation 4 21. 87 ( ) temperature variable ( ) reduction factor due to high temperature ( ) reduction factor due to high terminal voltage maximum motor torque during regenerative braking ( , ) additional brake signal for simulating compression friction ( ) additional brake signal if motor speed is to high brake signal generated by vehicle controller requested torque for the mode of regenerative braking : ( ) ( ) ( ) ( ) _ _ min max_ _ _ _ _ max_ _ min _ = = = = = = = = = − + ⋅ ⋅ ⋅ ϑ ϑ ϑ temperature high voltage high ter al regen idle speed high motor request regen request regen speed high motor idle regen voltage high ter al temperature high r r V T p v q p n p T where T p p n p v T r V r Equation 4 21 During phases of acceleration the requested motor torque is calculated according to Equation 4 22. ( ) reduction factor due to low terminal voltage [ 1] maximum motor torque during acceleration [ Nm] acceleration signal generated by the driver [ 1] requested torque in the acceleration mode [ Nm] : ( ) ( ) ( ) _ min max_ _ _ max_ _ _ min _ = = = = = ⋅ ⋅ ⋅ ⋅ voltage low ter al accel request accel request accel accel speed high motor voltage low ter al temperature high r V T q T where T q T r n r V r ϑ Equation 4 22 The requests for acceleration and braking are summed25 and from the combined request the actual motor torque is subtracted. The difference between the requested and actual motor torque is the error and fed into the proportional integral controller ( Equation 4 23). The output of this controller is limited to values between – 1 ( for maximum generatoric braking and + 1 ( for maximum acceleration) and then fed through a first order transfer function ( Equation 4 24 and 4 25). This transfer function can be interpreted in several ways: 25 Normally either the request for braking or for acceleration is zero. However, the possibility that the driver presses the acceleration pedal and the brake pedal at the same time is not excluded. 88 First it accounts for the filter time constants of the analog input low pass filters in a real power electronic design. Second it accounts for the time constant imposed by the motor coil inductivity and resistance. The output of the motor control algorithm could be interpreted as an analog signal that determines the state of the power switches and therefore controls the average motor current. ( )( ) T actual motor torque [ Nm] K Gain proportional integral controller [ 1/ Nm] Time constant of proportional integral controller [ sec] intermediate value [ 1] : actual MC MC _ _ _ _ = = = = + + − + − ⋅ = ⋅ τ τ y where T T T dt d T T T T dt dy K request brake request accel actual request brake request accel actual MC MC MC Equation 4 23 After the limitation block the intermediate value y changes to the intermediate value y1. intermediate request variable : 1 1 1 1 1 1 1 1 1 1 = = ≤ = ≥ = < < y where y  if y  y if y y y if  y Equation 4 24 Finally the output variable determining the requested motor torque is stated in Equation 4 25. The variable yout determines the requested fraction of the maximum motor torque available. 89 ( ) request variable for motor torque [ 1] filter time constant [ sec] : ( ) ( ) ( ) 1 = = ⋅ + = y t T where y t y t dt T dy t out filter out out filter Equation 4 25 90 4.3.3. Transmission The transmission modeled in this work is a 1 speed transmission including differential. Input variables are the motor shaft speed and the motor shaft torque. The output variables are wheel torque and wheel speed ( Figure 4 12). Figure 4 12: Block diagram of the transmission model. Similar to the electric drive train, the transmission translates energy flows in both directions. During phases of acceleration or cruising with constant speed the energy flow is from the motor to the wheels. During phases of deceleration in hybrid designs the energy flow is reversed from the wheels to the electric motor. The efficiency map has to describe both energy flow directions. Assuming that the motor speed and vehicle speed in this model are always positive, the two directions of energy flow result in a positive torque during acceleration phases and a negative torque during phases of regenerative braking ( in hybrid designs only). trans η motor shaft torque motor speed wheel torque transmission ratio wheel speed 91 Transmission ratio [ 1] Wheel torque [ Nm] T Motor shaft torque [ Nm] Mechanical power at the motor shaft [ W] Mechanical power at the wheels [ W] Transmission efficiency in regenerative brake mode [ 1] : _ _ _ _ trans_ motor _ _ _ _ trans_ motor = = = = = = ⋅ = = i T P P where T i T P P trans wheel trans motor trans motor trans wheel trans motor trans wheel trans motor trans wheel η η Equation 4 26 Transmission efficiency in regenerative brake mode [ 1] : trans_ regen _ _ _ _ trans_ regen = ⋅ = = η η where T T i P P trans wheel trans motor trans wheel trans motor Equation 4 27 Equations 4 26 and 4 27 describe the efficiency for both cases. The model assumes that the friction losses in the transmission are the same for both cases. These assumptions allow mirroring the 1st quadrant of the map ( positive torque and positive speed) into the 4th quadrant ( negative torque, positive speed). The complete efficiency map for the transmission is shown in Figure 4 13. 92 0 2000 4000 6000 8000 10000 12000  300  200  100 0 100 200 300 Shaft speed [ rpm] Shaft Torque [ Nm] 0.96 0.95 0.94 0.930.92 0.93 0.92 0.94 0.95 0.96 Motor Mode Generator Mode Figure 4 13: Efficiency map of the 1 speed transmission including differential. The inertia of the transmission is not explicitly considered in the transmission block. However, the transmission inertia can be transformed without any constraints either to the wheel side and added to the wheel inertia or to the motor side and added to the motor inertia. Equations 4 28 and 4 29 describe the transformation of the rotational inertia to the wheel side or to the motor side for the case of the two stage transmission ( reduction gear and differential). Figure 4 14 shows the rotational inertias at each stage. 93 wheels i1 i2 motor 1 Θ 2 Θ 3 Θ Figure 4 14: Schematic of the transmission. i Reduction ratio of the differential stage [ 1] i Reduction ratio of the reduction stage [ 1] Inertia of transmission components spinning with wheel speed [ kg m ] reduced by the ratio i1 [ kg m ] Inertia of transmission components spinning with the motor speed Inertia of transmission components spinning with motor speed [ kg m ] Total transmission inertia transformed to the motor side [ kg m ] : 1 1 2 1 2 3 2 2 2 1 2 _ _ 2 3 2 2 2 1 _ _ 1 = = Θ = ⋅ ⋅ Θ = Θ = ⋅ Θ = ⋅ Θ = Θ + ⋅ Θ + ⋅ Θ trans motor side trans motor side where i i Equation 4 28 ( ) to the wheel side [ kg m ] total transmission inertia transformed : 2 _ _ 1 2 2 1 2 _ _ 3 2 ⋅ Θ = Θ = Θ + ⋅ Θ + ⋅ Θ trans wheel side trans wheel side where i i Equation 4 29 94 4.3.4. Fuel Cell System In this work, the term fuel cell system is used to refer to the combined system of fuel cell stack, water and thermal management, air supply ( including compressor and expander), and fuel processor ( including reformer, clean up stages, and the burner for the anode off gas). Origin and Development The individual component models that comprise the overall fuel cell system have different origins. Springer ( Springer 1993 and 1998) described the fuel cell model fundamentals on the cell level. Friedman ( Friedman 1998) took the original Springer model, expanded it to a complete stack model and programmed this into SIMULINK. Cunningham ( Cunningham 1999) developed an air supply model for a direct hydrogen vehicle. Combining the stack model and the air supply model Friedman ( Friedman 1999) and Cunningham ( Cunningham 1999) developed an optimal operating strategy for the overall system of fuel cell stack and cathode air supply for the direct hydrogen case. Later, this initial model was expanded to cover the cases of indirect methanol fuel cell systems and indirect hydrocarbon systems ( Friedman 2000). In addition, Cunningham discussed the implications of an additional expander into the air system of a PEM fuel cell engine ( Cunningham 2000). Badrinarayanan developed a water and thermal management system, addressing the cooling loads and the issue of water sustainability. In a second step, Badrinarayanan added water and thermal management implications to the initial optimized operating strategy ( Badrinarayanan 2000). Friedman ( Friedman 2001) provided a complete discussion of the optimal control strategy, including water and th 



B 

C 

I 

S 


