ABSTRACTThis presentation focuses on several examples of partnershipsbetween tool suppliers and embedded software developers inwhich state-of-the-art tools are used to optimize a variety ofelectric and hybrid vehicle architectures. Projects withAutomotive OEMs, Tier One Suppliers as well as withacademic institutions will be described. Due to the growingcomplexity in multiple electronic control units (“ECUs”)inter-communicating over numerous network bus systems,combined with the challenge of controlling and maintainingcharges for electric motors, vehicle development would beimpossible without use of increasingly sophisticated tools.

Hybrid drive trains are much more complex thanconventional ones, they have at least one degree of freedommore. To achieve the development goals (e. g. optimum driveperformance and minimum CO2 emissions), an optimalconfiguration of combustion engine, battery and electricmachine(s) can only be defined with the help of computersimulation methods and tools.

Even if the major specs (speed/torque characteristics,performance, high voltage system) of all components aredefined and fixed, the operating strategy software (overallhybrid drive train coordination) still significantly influencesthese goals. The hybrid ECU with the vehicle's operatingstrategy is often developed, implemented and tested by meansof desktop simulation, rapid control prototyping, automaticcode generation as well as hard-ware-in-the-loop (HIL)simulation.

The e-mobility technology is developing very rapidly. Socooperative partnerships between OEMs, component and

controller suppliers and test equipment and tools companiescan be observed world-wide. For example: Lithium-ionbattery suppliers are working in cooperation with controllerdevelopers and tools companies on battery simulation andcontroller testing. Additionally, several trends can beobserved in the HEV development area:

• HIL simulation replaces track tests to handle the complexityand reduce costs

• Optimization tools are applied on mechanical test benchesto automatically find a good compromise betweendriveability, performance and emissions.

This paper presents application examples where thesepartnerships and new trends lead to successful products in theautomotive industry.

One special summary example of the use of embeddedsoftware development tools is the EcoCar Challenge , anindustry-supported project organized by the Department ofEnergy in conjunction with General Motors, and othersponsors, to develop expertise in the automotive developmentprocess, especially relative to producing “Greener” vehicles.In this project, competing Universities are supplied with abase vehicle and software development tools, such as rapidprototyping systems and HIL test systems. Numerouspowertrain architectures are developed and optimized duringthe course of the competition.

1). BACKGROUNDThe flurry of development activity in the hybrid vehiclepowertrain area over the recent several years is continuing todraw lot of excitement and press. The electrification oftoday's vehicles is approaching a level not foretold by many

Embedded Software Tools Enable Hybrid VehicleArchitecture Design and Optimization

2010-01-2308Published

10/19/2010

Kevin KottdSPACE Inc.

Peter WaeltermanndSPACE GmbH

Copyright © 2010 SAE International

pundits even a few years ago. Today, essentially everyvehicle OEM has announced new product developments withhybrid, or even fully electric powertrains.

In addition to the media and consumer excitement andconcerns, this activity has placed an emphasis on newdevelopments both in electric motors, battery systems,alternative energy storage devices (e.g. ultracapacitors,hydraulics and flywheels), power inverters, and especially incontrol systems. Not only does the newly electrifiedpowertrain bring requirements for its own control, but thenewly developed energy storage systems also energize manyauxiliary components, such as steering, brakes, temperaturecontrols, etc. In some cases, especially as the re-charginginfrastructure becomes more developed, the ability of thevehicle control system to interact with the grid will placeeven more demands on embedded controls.

In contrast to developing new versions of internal combustionpowertrains, the new hybrid movement is creatingopportunities for control systems to be developed fromscratch. In the case of IC engines, most control software hasbeen developed over the past 30 years in incremental steps asnew emission controls were added, or new features wereneeded. In those cases embedded software was commonly achallenge of integrating legacy code with newly developedfeatures. Developing control algorithms from scratch has prosand cons. The pro is that Model Based Development (MBD)techniques can be used without the challenge of integratingwith legacy code developed before MBD was used. The maincon is that there is often no proven baseline code which canbe relied on as robust and reliable.

Another area of complexity is the variety of hybridarchitectures. In the IC engine era, powertrain architecturaldecisions were basically between FWD, RWD, or AWD forwheel power, then Diesel or Gasoline for fuel source, then, avariety of cylinder configurations and fuel distributiontechnologies. The hybrid architecture decisions do noteliminate any of these previous degrees of freedom, butinstead add a whole host of additional significant variations:battery technology alternatives (NiMH, LiIon, PbAcid), mildhybrid, two mode hybrid, parallel hybrid, PHEV, range-extender HEV, full electric vehicle, and in the future possiblyfuel cell power.

In addition to the complexity added by new hybridpowertrain components, OEMs are finding a whole host ofnew suppliers to collaborate with, for example batterysuppliers such as A123, SAFT, Compact Power, EnergyConversion Devices, EnerDel, etc. Other players include suchcompanies as Azure Dynamics, TESLA, Fiskar, TH!nk, etc.

Considering all of the above, a primary issue to the success ofnew hybrid vehicles is the importance of system design andperformance. Complexity and economy concerns have

continuously driven a stronger emphasis on the vehicle as asystem even before the hybrid movement. Emphasis haschanged from optimizing the sub-sytems of the vehicleassembly i.e. primarily the powertrain, the chassis, and thebody, to optimizing the architecture and the overall system.The successful modern hybrid vehicle is analogous to asuccessful sports team. Individual stars cannot guaranteecontinuous success. Only an emphasis on a balanced set ofplayers and optimized teamwork produces lasting success.From an embedded controls perspective overall hybridvehicle analyzed as a system (including energy management)is key to success.

2). CHALLENGES IN HEVARCHITECTURE AND CONTROLDEVELOPMENTThere are several goals and challenges that influence thedevelopment of modern vehicles: Good performance anddriveability, maximum safety and good driving comfort oftenconflict with minimized fuel consumption, emissions andcarbon footprint. As mentioned in the previous chapter, thedevelopment of HEVs is a system approach where optimizedcomponents and corresponding component control systems(for example combustion engine, battery, electric motor(s),transmission and braking systems) have to be designed andoptimized in combination with the overall (hybrid) vehiclemanagement system.

Vehicle Management SystemThis hybrid vehicle management system contains the overalloperating strategy and guides the different subsystems(Figure 2.1). It decides, for example, when the combustionengine has to be started and stopped and in which operatingpoint (load vs. speed) the engine should do its job.Additionally it has to make sure that the battery state-of-charge (SOC) is always kept in the specified operating rangeso that on one hand, the electric-only mileage is stillsignificant, and on the other hand, that there is always somepotential for recharging it, for example in case of regenerativebraking. These intelligent systems are usually adaptive andadjust their operating strategy according to the traveled route(history) or the track planed by a navigation system (future).

Development ProcessesThe goal of this paper is the presentation of the tool chain andthe process steps in the development of the EV or HEVcontroller networks. The basis for this development is thewell-established V-cycle that is one of the standardapproaches in automotive software development. Figure 2.2shows the major phases of the V-cycle in general. Chapter 3will then introduce the different process steps in detail basedon case studies from the area of EV and HEV development.

Figure 2.1. Typical hybrid vehicle drivetrainconfiguration with the hybrid vehicle management

system and the underlying component-related controlsystems (ECUs).

Figure 2.2. V-Cycle for automotive softwaredevelopment, implementation and test.

3). CASE STUDIES FOR HEV/EVDEVELOPMENT PROJECTSIn this chapter, different case studies are presented thatillustrate the different development steps used in design andtest of HEV electronic control units. These case studies canbe seen as examples that explain the process steps in generaland the issues and challenges in the development of HEVelectronics in particular. At least one case study is describedfor each of the process steps shown in figure 2.2.

3.1). CONTROL DESIGN AND SYSTEMDEFINITIONThe component design and the system definition is thestarting point for dimensioning of the drivetrain. There areseveral tools available on the market, which support thedevelopment of the hybrid vehicle system configuration andsimulation, based on libraries of the individual components.Some of the tools use the effect-to-cause method [1], which isa kind of feed-forward simulation: Based on a driving cycleas an excitation, the operating points of the individualcomponents are calculated and from there the overall fuelconsumption and battery depletion/charge can be calculated.This method is not very useful for controller design andoptimization, but can be used for the fast comparison ofdifferent hybrid drive train structures and configurations.

The more common approach is the cause-effect method,which is the basis for nearly all hybrid vehicle simulationtools. Here a driver-model follows a driving cycle (task:speed control) or a simulated track (task: to choose the speedso that the car stays on the track). Many of these tools arebased on Matlab®/Simulink® or at least have an interface toSimulink or a Simulink model export capability (e. g. IAVVeLoDyn [2], PSAT (Power-train System Analysis Toolkit)by Argonne Nat. Lab. [3], dSPACE ASM [4]). Otherenvironments, such as Dymola, SimulationX, LMS AmeSim,CarSim etc. often use their own simulation environment andcorresponding solvers or support code export to Simulink.

Independent from the simulation environment, a precisesimulation requires accurate plant models and accurate ECUmodels (soft ECUs) i.e. controller models.

Plant ModelsThe variety of models for these kinds of applications is verywide, so a detailed analysis of the market would definitelyexceed the focus of this paper. An overview on commonmodeling approaches for the non-real time and real-timesimulation of engines and hybrid vehicle components can befound in the literature ([2], [5], [6]). Many of the models arebased on Matlab/Simulink. A general structure of a plantmodel is shown in figure 3.1.1.

Controller Models (ECU Models or Soft-ECUs)The controller models can be integrated as pure Simulinkmodels in the offline/desktop simulation or as the realfunctional ECU code (often in C), wrapped as an S-functionin Simulink or in other simulation environments (software-in-the-loop). In the early phase of the development, it is oftennot clear which software component will later be integratedin which physical ECU. Here, software architecture designtools such as DaVinci by Vector, SystemDesk by dSPACE[4], AutoSar Builder by Geensoft (and to some extent Intecrioby ETAS) are applied to define the software architecture or

the distributed control system independently from anyphysical device (ECU) and its implementation.

Figure 3.1.1. Plant model components and theirinteraction for the simulation of HEV drivetrains [4].

3.2). RAPID CONTROL PROTOTYPING:ON A TESTBENCH OR ON THE TRACKAfter the architecture of the system is decided, the basiccontrol strategy is developed, and control algorithms havebeen drafted in a graphical language such as Simulink, thenext development challenge is to implement the draftalgorithms in executable code into a prototype ECU. Manyissues arise when real-time control demands from the ECU/microprocessor conflict with the intent of the draft algorithmif the system even runs at all. Several makers of RapidControl Prototyping systems now offer hardware andsoftware packages that take Simulink/StateFlow controlmodels and translate them into code that can be tested with aprototype ECU containing a real microprocessor and I/Ohardware.

Figure 3.2.1. Hybridized ML350 by Magna Steyr.

An example of this phase of the development cycle is theHybrid Drive System developed by Magna Steyr incooperation with its suppliers and partners to build aMercedes M-class HySUV demo vehicle.

Magna Steyr, working with Magna Powertrain, and SiemensVDO (now Continental) replaced the automatic transmissionand transfer case in the Mercedes ML350 (see figure 3.2.2)and installed two electric motors - one which exclusivelypowers the front wheels and one which works in concert withthe IC engine to power the rear wheels. Four hydraulicallyactuated multi-plate clutches control the torque flow to eachwheel. A 70 kW / 360V lithium ion battery system provideselectrical energy storage and several engine accessories wereconverted to electrically operated components.

All hybrid drivetrain components are controlled with just onecontroller prototyping system (refer to Figure 3.2.3 below)using an auxiliary extendable driver hardware system(RapidPro by dSPACE) to provide actuator drivers, sensor I/O and hardware diagnostic interfaces.

The control software was developed to contain the functionsand interfaces of the entire driveline torque path including:

• Determine torque requested by driver based on acceleratorpedal, brake pedal and gear level positions

• Control the distribution of torque to the axles based ondriver's demand, optimum traction, and availability of the ICengine and 2 electric motors

• Consider efficiency, dynamics, battery charge status,comfort and thermal conditions to distribute torque and selectthe appropriate gear

• Manage torque sources and control transient drivelineprocesses

• Control components in the automated manual transmissionand the all wheel drive module (E4WD)

This was a complex control development project whichinvolved a careful step-by-step process to ensure success.Following are some statistics from the software developedusing the rapid control prototyping system:

• 257,000 lines of generated C code

• 44,000 model blocks

• 4.5 MB memory control application

One indication of success of this new control system is thedyno-generated charts of typical engine operating conditionsversus efficiency. Refer to figure 3.2.5 (graphs of torque vs.engine speed) A comparison of the engine operatingconditions between IC engine only and the hybridizedpowertrain indicates significant shift of operating points to

more efficient areas. Many of the low efficiency operatingpoints of the IC engine have been replaced or shifted to eitherpurely electric operation or electrical assist operation

Rapid Control Prototyping has become a standard method fordeveloping and optimizing algorithms in HEV controlapplications. Several other applications are included in thereferences ([7], [8]).

3.3). TARGET CODE GENERATIONAs ECU code becomes more complex and requires morememory and processor resource, one of the significantfeatures of Model-Based Development (MDB) that bringsgreat efficiencies is the use of Auto Code Generation (ACG)technology. Control Algorithms developed in model-based

graphical languages such as Simulink can be converted toproduction code for implementation in an ECU veryeffectively. Even more importantly, as revisions to thealgorithms due to design changes are developed, code can beregenerated in minutes versus weeks as is often the casewhere ACG is not used.

Modern ACG systems not only generate code faster but offerfeatures to streamline code review and enhance overall codequality. Features such as the following are becoming moreimportant in embedded software development projects:

Figure 3.2.2. Diagram of key components installed in the ML350 to hybridize the vehicle.

Figure 3.2.3. Diagram illustrating the control system architecture and its connections to the vehicle data network.

Figure 3.2.4. A large number of modular softwarecomponents ensure that the hybrid drive implements the

driver's wishes in an optimum manner.

Figure 3.2.5. Efficiency of IC only engine operation (top)versus hybrid operation (bottom).

• Ease of performing Model-in-the-Loop (MIL), Software-in-the-Loop (SIL), and Processor-in-the-Loop (PIL) simulations

• Coverage Analysis - ensures that none of the code is useless

• Automatic Test Case Generation and Code Validation

• Model Validation by Formal Verification

• Automatic Style Checking for Models

One recent example of the successful application of ACG is ajoint venture between Johnson Controls and SAFT AdvancedPower Solutions (JC-S). JC-S recently developed an efficienthigh voltage lithium-ion battery management system for theMercedes-Benz S 400 HYBRID - with a mild hybrid drivesystem.

Figure 3.3.1. Battery assembly, mild hybrid startingmotor and their installed locations.

Some critical features for this battery management system(BMS) are listed below; The BMS

• is contained in a separate dedicated ECU installed in thebattery assembly,

• is networked to all hybrid-control ECUs including theclimate control ECU (for battery temperature management),

• implements numerous safety checks to ensure high voltagecontacts are live only when in operation,

• provides charge level and power flow data to the instrumentcluster graphics display

• includes computation of current, voltage, and power limits,and monitors the battery aging,

• controls current flow and voltage limits to maintain batterytemperatures between 30 to 50 deg C, and

• performs cell balancing to handle charge differencesbetween the 35 high voltage cells to extend battery life. Eachcell is recharged individually on the basis of a load chargeanalysis of that particular cell.

Figure 3.3.2. Close up of Lithium-Ion battery assembly.

Because this was the first control developed for lithium-ionbattery applications in a mild hybrid, the controller softwarehad to be developed from scratch, without adapting legacycode. Modeling guidelines were adapted from therecommendations of the ACG tool supplier, for the bestpossible implementation and most efficient production code.Figure 3.3.3, shows the flow of development phases in thisproject.

Some of the major successes realized in this project include:

• New mild-hybrid drive battery management controllermodel successfully developed from scratch

• Run-time behavior and the resource consumption tested byprocessor-in-the-loop (PIL) simulation. Real-timerequirements fulfilled in all use cases

• Function algorithm designed with Simulink/TargetLink toeasily work with other ECUs containing similarly developedalgorithms

• Production code for fix point processor TriCore TC1796generated with TargetLink

• approx. 25,000 lines of code generated

• Code validation per MIL, SIL, PIL simulation

Figure 3.3.3. Phases of the hybrid vehicle controllersoftware development project.

3.4). HARDWARE-IN-THE-LOOPSIMULATIONWhen the ECU has been programmed, its functions can betested manually or automatically by means of hard-ware-in-the-loop simulation (HIL). Unlike test drives in a real vehicle,these tests are performed in the lab, so that errors that occurcan be reproduced at any time. The HIL test system replacesthe real environment of the ECU and the tests can beexecuted in any conceivable test scenario, systematically andreproducibly with test automation. As a result, complicatedand expensive test runs in the real environment (test track ortest bench, winter tests, summer tests) can be reduced to aminimum. The key components of the HIL simulation are themodels of the plant in combination with fast and precise I/Oand communication interfaces. Figure 3.4.1 shows the typicalsignal flow in a real system compared to HIL simulation.

Figure 3.4.1. Signal flows in a real system (top) and inHIL simulation (bottom left and right) [9].

Like the aforementioned process steps, HIL simulation hasbeen established as a standard E/E development step in theautomotive industry. HIL simulator applications vary fromsingle ECU testers over domain-specific simulators(powertrain, body, interior, infotainment) to full virtualvehicles with all the ECUs of a vehicle (platform).

HIL in Hybrid Vehicle ApplicationsEV and HEV applications are an important use case of HILsimulation. The simulation of electric machines and batteriesare very challenging and call for some specialized hardwareand software solutions. The basic structure of an electricalmachine in a vehicle is shown in figure 3.4.2. The controlleritself, with its current controller, sends pulse-width-modulated control signals to the power stages, which thenswitch the real voltages and currents for the electric motor.

This generates torques on a vehicle component viamechanical shafts. For control, motor currents and the motorposition are usually returned.

A basic difference between electric machines and othervehicle components is that the machine is controlled at a veryhigh clock rate (typ. 10-20 KHz). This places significant newdemands on the HIL simulation. I/O sampling rates in themillisecond range and mean value models, which are used forcombustion engines, are not sufficient for fast current andposition control. Special FPGA-based hardware is commonlyused for this purpose, for measuring the PWM control signalor for simulating incremental encoders or resolvers.Moreover, small model parts can be simulated directly on theFPGA to achieve simulation step sizes in the sub-microsecond range.

Figure 3.4.2. Basic structure of electric drives in vehiclesand the three possible interfaces to an HIL system.

Figure 3.4.2 shows the possible interfaces between an HILsystem and the electric machine's ECU. Depending on theapplication and the modeling depth, the interfaces can bedefined and implemented either on the mechanical level (e.g.with mechanical load motors), on the electrical power level(by means of electronic load simulation), or on the signallevel (without relevant power). HIL solutions for all thesecases are available on the market and have been published[6].

HIL System for a Battery Management System(BMS) for LiIon Batteries (BMW)This case study describes the special challenge in simulatingthe real-time behaviour of a LiIon battery necessary to testthe corresponding BMS. The main tasks of a BMS aretemperature management, charge control, several safetyfunctions under high voltage conditions, isolation monitoringand - in case of any failures - onboard diagnostic functions.Additionally it has to supervise the cell voltages to calculatethe state-of-charge (SOC) of the battery and to perform cell

balancing by (dis)charging certain cells. The structure of aBMS is shown in figure 3.4.3.

In this particular application, the HIL system behaves like areal battery and allows testing all the aforementionedfeatures. It contains an electrical failure simulation unit tocheck the diagnostic and safety features of the BMS.Additionally, variable resistors can be switched between thesimulated battery poles and the vehicles GND or Vbatt linesto test the isolation monitoring etc. Finally, the cell voltagesimulation has to support cell balancing. This means, a cellmodule emulator, that acts like a current source to the BMS,

simulates the cell voltage which supports the discharge ofindividual cells. Figure 3.4.4 shows the structure of the HILsystem that BMW established successfully in their E/Edevelopment processes. More details of that application canbe found in the literature [10].

HIL system for the drive system of the Misubishi i-MiEVOne successful example for the usage of HIL in the EVdomain is the test of the electronics of Mitsubishi's newelectric vehicle, i-MiEV (Figure 3.4.5 and [11]). The i-

Figure 3.4.3. The BMS performs battery management, in conjunction with the cell ECUs (CEs), which directly monitor thebattery modules.

Figure 3.4.4. The BMS, some cell module emulators, and real parts are integrated into the HIL simulator setup.

MiEV's electronic platform is characterized by a distributedcontrol system that uses five dedicated ECUs. Four ECUs(one for each function) are for a special battery unit, anindividual cell monitoring unit, an electric motor control unit,and an onboard recharging unit. These four ECUs areconnected to the fifth ECU, the overall electric vehicle ECU(EV ECU) to offer the various controls an electric vehicleneeds. Mitsubishi ran rigorous tests to ensure the quality ofthe software, yet still managed to cut the time-to-market.

In executing the testing, it was necessary to adapt the testdesign content for the test patterns quickly and accurately.For the sake of analysis, a high level of replication wasneeded when software bugs were detected. Therefore, adSPACE Simulator Mid-Size was used to simulate useroperation and the inputs to the ECUs accompanying it duringthe design process. By supervising the inter-ECUcommunication (via CAN-Bus), a large number of input testpatterns were applied to systematically verify the drivesystem of the i-MiEV. An actual vehicle was used for the realload on the HIL simulator and the test automation softwareAutomationDesk was applied as a means of creating testpatterns quickly. The HIL simulation proved to be extremelyeffective in ensuring the quality of the software delivered onschedule. According to Mitsubishi, the verification of thesoftware quality within the time available would have beenvery problematic without HIL simulation.

Figure 3.4.5. The Mitsubishi i-MiEV.

Another interesting application is an HIL system to test theentire ECU network of the 2010 VW Touareg Hybrid, aparallel hybrid vehicle. Volkswagen applied the HILtechnology successfully for full network testing of all theECUs of their high-end SUV. For details, please refer to thereferences [12].

3.5). ECU CALIBRATION, PARAMETERFINE TUNING, AND OPTIMIZATIONThe calibration of software parameters is a major milestonein the development of ECUs. Whether in test drives, on a testbench, or in earlier phases of the development, ECUcalibration, measurement and diagnostics are indispensible. Itis often the last step in the development before start ofproduction of the vehicle and thus, before the vehicle arrivesat its customers.

As a result, ECU calibration is still one of the most importantand also most expensive steps of the development of modernvehicles. Hundreds of engineers and tons of vehicles andequipment are shipped around the world to find the rightenvironment and the optimum test conditions for calibrationwork. Well established calibration tools are available from,for example ETAS (Inca), Vector (Canape), ATI (Vision) anddSPACE (CalDesk).

Even if the calibration work can not be avoided completely,the trend to do more development virtually and to solveproblems earlier in the process (frontloading) can also beapplied to calibration. In the engine development area,calibration and optimization methods have been established,that allow a fully automated pre-calibration of an engine ECUon a dynamic engine test bench by means of online DOE(design of experiment) methods. Concepts and tools for thishave been presented among others, by AVL, IAV (“rapidcalibration”) and Ricardo.

Adapting this approach to full HEV drivetrains, combining itwith real-time simulation of the vehicle dynamics and with an(online) optimization and DOE system (for example AVLCameo), leads to an automated optimization procedure thatcan be performed on dynamic test benches (figure 3.5.1).

Figure 3.5.1. Test bench with parallel hybrid powertrain(engine, electric drive, battery, transmission, and

corresponding controllers) in combination with a real-time simulation (HIL) environment. This environment

allows dynamic optimization procedures and onlinecalibration of a hybrid drivetrain's ECUs.

This test bench system is a very powerful tool that allowsautomated or semi-automated studies and optimizationprocedures, incorporating closed-loop dynamic drivingmaneuvers, for example, to:

• develop and optimize smooth engine start procedures andengine kick-in,

• use objective driveability evaluation to qualify and quantifythe dynamic responses of the drivetrain

• evaluate the influence of start-stop, engine kick-in,regenerative braking etc. on the vehicle dynamics, with thereal ECUs,

• evaluate the influence of vehicle dynamics controlinterventions (ABS, ESP, steering) on the behaviour of thehybrid vehicle drivetrain,

• optimize drive comfort in combination with minimized fuelconsumption and emissions (for example during gearchanges) to minimize jerk, accelerations, …

4). UNIVERSITY STUDENTSDEVELOPING ALTERNATE HYBRIDVEHICLE ARCHITECTURESAn interesting example of the automotive industryemphasizing the importance of modern software development

tools is the EcoCar project. EcoCAR: The NeXt Challenge isa vehicle technology engineering competition for students inadvanced collegiate programs established by the UnitedStates Department of Energy (DOE) and General Motors(GM), and managed by Argonne National Laboratory(www.ecocarchallenge.org). It is a three-year project whichbegan in late 2008 and is now entering year 3.

Over 60 universities applied for this competition, each withan extensive proposal detailing among other things how theuniversity would support the competing team and how thelessons learned would be applied in future curricula.Currently, 16 universities across North America (including 3Canadian) having been selected on the basis of outstandingproposals, are in the competition. A major goal of the projectis to reduce the environmental impact of an automobile byminimizing the vehicle's fuel consumption and reducing itsemissions without sacrificing its performance, safety andconsumer appeal. Students learn a real-world engineeringprocess (figure 4.1) to design and integrate their advancedtechnology solutions into a GM-donated compact cross-overSUV. All Universities started with the same vehicle, but haveprogressed to develop different powertrain architecturesbased on virtual simulations using a variety of modelingsystems.

Students are designing and building advanced propulsionsolutions that are based on vehicle categories from theCalifornia Air Resources Board (CARB) zero emissionsvehicle (ZEV) regulations. They explore a variety of cutting-edge clean vehicle solutions, including full-function electric,range-extended electric, hybrid, plug-in hybrid and fuel celltechnologies. Students also had the freedom to choosealternative fuels such as ethanol, biodiesel and hydrogen intheir new architectures. Figure 4.2 is a matrix describingsome of the major features of each team's project.

GM has provided all teams with instruction and mentoring ina version of GM's global vehicle development process(GVDP, figure 4.1). There have been previous studentengineering competitions which focused on vehicle hardwaremodifications. EcoCAR, is the first competitive collegiateproject which featured a strong emphasis on system andcontrols modeling and simulation, as well as subsystemdevelopment and testing.

This project is a collaborative effort of major proportions.General Motors is providing vehicles, vehicle components,seed money, technical mentoring and operational support.The U.S. Department of Energy and its research anddevelopment arm, Argonne National Laboratory, is providingcompetition management, team evaluation and technical andlogistical support. Additionally over 25 corporate andgovernmental sponsors provide components, money,developmental tools and mentoring to the competinguniversities.

Figure 4.3 contains a diagram illustrating the overall projectbroken down by the main areas of development focus:Mechanical, Electrical and Controls domains. In the first yearof EcoCAR, participating teams used math-based designtools-such as Argonne's Powertrain Systems Analysis toolkit(PSAT) or similar vehicle models research-to comparepotential architectures and select an advanced vehiclepowertrain that meets the goals of the competition. Teamsused CAD software to ensure that their chosen componentsfit into their vehicle and that the electrical, mechanical andsoftware systems function properly. All teams are employingsoftware-in-the-loop (SIL) and hardware-in-the-loop (HIL)technologies to develop controls and subsystems.

In the last two years of the competition, students actuallymodify the supplied production vehicle and develop aworking vehicle using their first year design to meet thecompetition's goals. The teams come together at the end ofeach academic year to compete against each other in morethan a dozen static and dynamic events designed to measurethe success of their project.

During each weeklong competition, student teamsdemonstrate the modified vehicles to industry expertvolunteer judges to prove that their designs meet or exceedthe following goals relative to the original production vehicle:

Figure 4.1. General Motors global vehicle development process.

Figure 4.2. EcoCar team vehicle architecture summary.

• Incorporate technologies that reduce petroleum energyconsumption on the basis of a well-to-wheel (WTW) analysisof the total fuel cycle,

• Increase vehicle energy efficiency,

• Reduce WTW greenhouse gas (GHG) and regulatedemissions, and

• Maintain consumer acceptability in the areas ofperformance, utility and safety.

This program has been highly successful in stimulating abetter education in the competing universities in bothelectrical, software and automotive development processes, inaddition to giving students first hand experience with theembedded software development tools that are the state of theart in this industry.

5). SUMMARYFollowing the process described by the V-cycle metaphor,this paper described a series of development challenges thathave been met using state of the art tools. The increasingcomplexity of networked controls in the trend to develophybrid and fully electric vehicles has increased the focus ofOEM and Tier One developers on technologies to ensureoptimum quality of ECU software, and to minimize time tomarket. Specifically:

Figure 4.4. The EcoCar Challenge involves significantcollaboration between a major OEM, the Government,

suppliers, and universities. The ultimate goal is toencourage development of green technologies for future

vehicles.

1). Plant Models and Controller Models are commonlydesigned using a combination of high level programminglanguages and graphical environments.

2). Draft control algorithms are developed and optimizedusing a process referred to as rapid control prototyping whichutilizes a specialized development ECU containing manyfeatures to allow flexible, efficient, and quick prototypeevaluations.

Figure 4.3. Outline of EcoCar project by year and by domain.

3). ECU Code can now be relatively easily converted fromprototype algorithm to production ready C code using aprocess identified as Target Code Generation, or sometimes“Automatic Code Generation”.

4). ECU Code, no matter how developed, is beingthoroughly tested in a number of configurations ranging fromcomponent control level to full vehicle network level usingHardware-in-the-Loop technology. Such technology offersnumerous benefits including shorter time to market, andsignificantly improved quality.

5). The last and often most expensive step in embeddedcontrol development, is ECU Calibration, which incorporatesthe fine tuning of system and control parameters in thevehicle or on a testbench.

From the examples cited in this paper it is clear that thechallenges posed by complex hybrid powertrain controladaptations in automobiles are being introduced moreeffectively and efficiently using the latest embedded softwaredevelopment tools. It is not much of a stretch to say thatwithout these tools, hybrid vehicles would not be feasiblydeveloped in an acceptable time frame with the necessaryquality. Certainly as technology for electrification of vehiclesadvance, software development tools will continue toadvance and play a critical part, ensuring quicker times tomarket and higher quality.

REFERENCES1. Swann, J. and Green, A., “The Development of aSimulation Software Tool for Evaluating AdvancedPowertrain Solutions and New Technology Vehicles,” SAETechnical Paper 981125, 1998, doi:10.4271/981125.2. Lindemann, M.; Wolter, T.-M.; Freimann, R.; Fengler, S.:“Simulation as a Solution for Designing Hybrid Powertrains”.ATZ worldwide eMagazines Edition: 2009-05; http://www.atzonline.com.3. Argonne National Laboratory: “PSAT (Powertrain SystemAnalysis Toolkit)” http://www.transportation.anl.gov/modeling_simulation/PSAT/.4. dSPACE GmbH: dSPACE TargetLink, AutomotiveSimulation Models (ASM), RapidPro, MicroAutoBox,SystemDesk, CalDesk, AutomationDesk Product Information2010, www.dspace.com.5. Schuette, H. and Ploeger, M., “Hardware-in-the-LoopTesting of Engine Control Units - A Technical Survey,” SAETechnical Paper 2007-01-0500, 2007, doi:10.4271/2007-01-0500.6. Wagener, A., Schulte, T., Waeltermann, P., and Schuette,H., “Hardware-in-the-Loop Test Systems for Electric Motorsin Advanced Powertrain Applications,” SAE Technical Paper2007-01-0498, 2007, doi:10.4271/2007-01-0498.7. Brun, M., “Deutz and Atlas Weyhausen take up dSpacefor hybrid-drive development,” SAE Off Highway

Engineering Online, September/October 2009, http://www.sae.org/mags/SOHE/TOOLS/6715.

8. Koprubasi, K.: “Control of a Power-Split Hybrid-ElectricSUV”. dSPACE News 3/2007, page 16ff.

9. Waeltermann, P.: “Hardware-in-the-Loop: TheTechnology for Testing Electronic Controls in AutomotiveEngineering”: 6th Paderborn Workshop “DesigningMechatronic Systems” Paderborn, Germany, 2009 http://www.dspace.de/shared/data/pdf/paper/HIL_Overview_Waeltermann_03_E.pdf.

10. “Virtual energy cells: dSPACE HIL simulators at theBMW group - testing lithium ion battery managementsystems” dSPACE Magazine 1/2010, page 7ff.

11. Hayafune, K.; Kaneda, M.: “Driving with no emissions -First Mitsubishi electric vehicle ready for launch” dSPACEMagazine 3/2009, page 14ff

12. Schueler, R; Brand, M.; Claus, C: “Touareg Hybrid -electrified and electrifying” dSPACE Magazine 2/2010, page6ff.

CONTACT INFORMATIONKevin KottPresidentdSPACE Inc.50131 Pontiac Trail, Wixom, MI 48393, USAkkott@dspaceinc.com

Dr. Peter WaeltermannGroup Manager EngineeringApplications/Engineering Dept.dSPACE GmbHRathenaustraße 26, D-33102 Paderborn, Germanypwaeltermann@dspace.de

DEFINITIONS/ABBREVIATIONSACG

Automatic Code Generation

AMTAutomated Manual Transmission

AWD, FWD, RWDAll-/Front/Rear Wheel Drive

BMSBattery Management System

CANController Area Network

CARBCalifornia Air Resources Board

DOEDepartment of Energy, Design of Experiment

ECUElectronic Control Unit

ESPElectronic Stability Program

FPGAField-Programmable Gate Array

(H)EV(Hybrid) Electric Vehicle

HIL, MIL. SIL, PILHardware/Model/Software/Processor-in-the-Loop

HMIHuman Machine Interface

LiIonLithium Ion (Battery)

MBDModel-Based Design

NiMHNickel Metal Hydride (Battery)

OEMOriginal Equipment Manufacturer

PHEVPlug-In Hybrid Electric Vehicle

RCPRapid Control Prototyping

SOCState-of-Charge

ZEVZero-Emission-Vehicle

The Engineering Meetings Board has approved this paper for publication. It hassuccessfully completed SAE's peer review process under the supervision of the sessionorganizer. This process requires a minimum of three (3) reviews by industry experts.

All rights reserved. No part of this publication may be reproduced, stored in aretrieval system, or transmitted, in any form or by any means, electronic, mechanical,photocopying, recording, or otherwise, without the prior written permission of SAE.

ISSN 0148-7191

doi:10.4271/2010-01-2308

Positions and opinions advanced in this paper are those of the author(s) and notnecessarily those of SAE. The author is solely responsible for the content of the paper.

SAE Customer Service:Tel: 877-606-7323 (inside USA and Canada)Tel: 724-776-4970 (outside USA)Fax: 724-776-0790Email: CustomerService@sae.orgSAE Web Address: http://www.sae.orgPrinted in USA