2004-01-1240 An Overview of Hardware-In-the-Loop ... - dSPACE

SAE TECHNICALPAPER SERIES 2004-01-1240An Overview of Hardware-In-the-LoopTesting Systems at VisteonSyed Nabi and Mahesh BalikeVisteon CorporationJace Allen and Kevin RzemiendSPACE Inc.Reprinted From: Testing and Instrumentation 2004(SP-1871)2004 SAE World CongressDetroit, MichiganMarch 8-11, 2004400 Commonwealth Drive, Warrendale, PA 15096-0001 U.S.A. Tel: (724) 776-4841 Fax: (724) 776-5760 Web: www.sae.org

All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, ortransmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise,without the prior written permission of SAE.For permission and licensing requests contact:SAE Permissions400 Commonwealth DriveWarrendale, PA 15096-0001-USAEmail: permissions@sae.orgFax: 724-772-4891Tel: 724-772-4028For multiple print copies contact:SAE Customer ServiceTel: 877-606-7323 (inside USA and Canada)Tel: 724-776-4970 (outside USA)Fax: 724-776-1615Email: CustomerService@sae.orgISBN 0-7680-1319-4Copyright © 2004 SAE InternationalPositions and opinions advanced in this paper are those of the author(s) and not necessarily those of SAE.The author is solely responsible for the content of the paper. A process is available by which discussionswill be printed with the paper if it is published in SAE Transactions.Persons wishing to submit papers to be considered for presentation or publication by SAE should send themanuscript or a 300 word abstract of a proposed manuscript to: Secretary, Engineering Meetings Board, SAE.Printed in USA

2004-01-1240An Overview of Hardware-In-the-Loop TestingSystems at VisteonSyed Nabi and Mahesh BalikeVisteon CorporationJace Allen and Kevin RzemiendSPACE Inc.Copyright © 2004 SAE InternationalABSTRACTThis paper discusses our experiences on theimplementation and benefits of using the Hardware-Inthe-Loop(HIL) systems for Powertrain control systemsoftware verification and validation. The Visteon HILsystem integrated with several off-the-shelf diagnosticsand calibration tools is briefly explained. Further,discussions on test automation sequence control andfailure insertion are outlined The capabilities andadvantages of using HIL for unit level software testing,open loop and closed-loop system testing, fault insertionand test automation are described. HIL also facilitatesSoftware and Hardware Interface validation testing withlow-level driver and platform software. This paperattempts to show the experiences with and capabilitiesof these HIL systems.and cost involved with the testing of complex electronicand component systems forced the automotive industryto investigate and invest in better testing methodologies.The advancement of computer technology, availability ofhighly efficient low cost compute engines and, readilyavailable off-the-shelf systems, have pushed the viabilityand usability of the HIL technology from the Defenseand Aerospace industry to the Automotive industry.After the successful use of HIL simulation technologiesin the Aerospace industry, the Automotive industryadopted the technique in the 1990s. Several successfulpartial and complete closed loop simulations can becited in the literature since then [1,2].INTRODUCTIONHIL technology has been in wide use in Defense andAerospace industry as early as the 1950s. In spite of thehigh cost of the HIL technology in those days, theDefense and Aerospace industry took advantage of HILsystems mainly due to the risk of human life involved inthe real time system and the extremely expensiveprototype systems under test. The automotive industrydid not embrace HIL technology for development andtesting of automotive control systems mainly due to itshigh cost and feasibility of using the HIL technology forcomparatively simpler control systems.Over the years, the automotive industry started addingmore and more diverse embedded software controlledelectronic components in vehicles to improveperformance; efficiency and comfort as well as to becompliant with government regulated and mandatedemission requirements. The pressure of increasedcomplexity in the design and verification process timingFigure 1 Traditional Development ProcessThe traditional design, development and verificationprocess of automotive embedded control systemsoftware comprises several steps and iterations asdepicted in Figure 1. As illustrated in the figure, duringthe design and verification process the designrequirements may change due to internal process,

addition of new requirement, and refinement ofrequirement. The late changes in requirements cause asignificant impact on the development and testing timeof control system software and this iterative loop ofrequirement change, development and testing is notvery efficient. Further, obtaining a prototype vehicleduring the early software developmental phase isextremely difficult and cost prohibitive, especially for anon-OEM (Original Equipment Manufacturer)companies.A Powertrain Control Module (PCM) is one of the mostcomplex electronic embedded control systems in themodern vehicle. The PCM software therefore requires arigorous and through testing of its functionality. In orderto manage the increasing demand of technology in PCMdesign, Visteon Corporation started investigating thepossibilities of using a state-of-the-art HIL system forPCM software development and verification in 1998. HILtechnology is best suited to perform a complete andrigorous testing of the Embedded control systemsoftware of PCM. Visteon anticipated that HILsimulation would improve quality and also reducedevelopment time and cost. At the same time the HILsystem based development and testing will complementthe implementation of model based softwaredevelopment (MBD) technology. The initial strategy wasto implement HIL for PCM software testing only.However, over time it became apparent that the sameimplementation could be easily tailored for theSoftware/Hardware Interface validation as well.Implementation of a HIL system for testing during thedevelopment phase of PCM software also addressesother issues associated with the traditional bench testenvironment. Some of the issues associated with thetraditional bench test environment are uncontrolled andnon-repeatable tests without proper closed loopfeedback to perform a complete system verification andvalidation of the software in real time, difficulty inachieving consistency, manual mode of operation for setpoints, ad hock data capture and test results and thenear impossible task of testing the complex closed loopcontrol algorithms of the PCM software in an open loopbench test environment.Visteon has proven that there are significant benefits ofOpen Loop HIL testing during the initial phase ofsoftware development by performing unit level softwareverification. HIL testing is also used for verification ofthe Software and Hardware Interface of the low-levelplatform software. The integration of HIL systems withcalibration and diagnostic tools also provides significantadvantages with closed loop simulation and testing ofcompletely integrated software in real time on the bench.Several other features of HIL such as test automation,test stimulus generation, and fault-insertion testing areaddressed. These HIL systems use Python, anadvanced test scripting language, to control testsequences and coordinate the variety of interfacesnecessary for a particular test, or a set of tests. Thistest-scripting feature of the HIL system gives the testdeveloper the capability to implement full lights-outtesting scenarios and also allow for exact reproductionfor subsequent DUT (Device Under Test) regressiontesting. The HIL systems also have the capability toinject stimulus signals into the DUT, which can be usedfor a variety of purposes. These include drive cycles foran engine or vehicle test, and also response datahistories for component validation.Finally, the interfaces between the PCM and the plant(Vehicle, Engine, etc) need to be tested. When failuresoccur with sensors or actuators, the PCM generallyneeds to detect these and provide for strategies toovercome them. Using the HIL systems, it is fullypossible to simulate almost any type of failure that acontroller could experience. This failure testing can alsobe performed during critical control periods, which mightnot be possible to implement on the actual target plant.Figure 2 Visteon HIL ArchitectureVISTEON HIL SYSTEMARCHITECTUREThe Visteon HIL software-testing environment is built onmodified dSPACE midsize and/or full size enginesimulators integrated with several off the shelf tools. Thesystem architecture of the Visteon HIL system is shownin block diagram in Figure 2. The Visteon HIL simulatoris housed inside a 19” desktop rack containing a PowerPC processor board for real time computation, aspecialized automotive HIL I/O board, additional I/Ocards, required signal conditioning boards, load boardswith fault simulation capability as the main component ofthe simulator. The system is also equipped with a

emote control power supply. The power supply can becontrolled in real time during simulation, which providesthe capability of vehicle battery simulation The PCM isphysically connected to the HIL simulator by customizedharnesses for I/O routing either directly or throughswitchable breakout boxes. Further, it is possible toattach actual physical component assemblies to the HILsystem using an external interface. The system alsoaccommodates integration of off-the-shelf calibrationand diagnostic tools. The integration of calibration anddiagnostic tools with the HIL system provides thecapability of automated testing of very complexPowertrain control system software. [3]One of the critical parts of this HIL system is the loadsubsystem. It is very critical to have an appropriate loadfor the actuator signals in order for the PCM software towork properly. In order to accommodate the specialcharacteristics of certain actuators the system connectsto a specially designed company proprietary loadsubsystem. The closed loop simulation of the systemrequires appropriate feedback response from theactuator load to satisfy the smart device driver integratedcircuits (IC) and advanced On Board Diagnostics (OBD)system software. Without the appropriate closed loopsystem and actuator load feedback, the PCM controllerwill enter a fault mode and will defeat the purpose ofvalidation of the system software. For the completeclosed loop system simulation another significationrequirement is the representative plant model. The plantmodel should represent the physical behavior of theplant; in our implementation the plant consists of theengine, the transmission and other ancillarycomponents.interfaces. Refer to Figure 3 to see a depiction of someof these interfaces. Below is a list of just some of thephases required to perform HIL testing:• Control of the test sequence to run and ability toregressively test• Injection of test stimulus in real-time• Access to the model parameters and data andcontrol of the simulation state• Access to external devices (Testers, Voltmeters,etc.)• Access to and control of PCM interfaces (diagnostictools)• Ability to generate test documentation and save testdata• Test data analysis during the testThe system chosen to perform the testing must providethe power to perform the above tasks, yet needs to berelatively easy to use in order to minimize testdevelopment costs and allow for changes in the testingprocess. The system chosen by Visteon is the softwaretool ControlDesk ®2 , by dSPACE. ControlDesk providesall of the capabilities needed for a HIL test system,including hardware/model management, data acquisitionand graphical user-interface capabilities. The TestAutomation extension of ControlDesk is based on thepython language, and it provides the interface librariesneeded to automate the tools and programs needed toperform the above listed tasks.A set of plant models suitable for real-time simulationhas been developed and validated in-house, torepresent various automotive subsystems for differentpowertrain applications. The real time executable plantmodels are developed in MATLAB ® , Simulink ®andStateflow ®1 , and are composed of flexible andconfigurable component and sub component models.Physical component and systems are represented inmathematical models. These representative plantmodels are developed with significant and adequatedetail to perform the controller software algorithmverification and validation.TEST AUTOMATION SEQUENCE CONTROL ANDDESIGNPhases of testing and automationThe task of powertrain hardware and software testingusing HIL simulation requires many phases andFigure 3 Interfaces in HIL SystemTest sequences and scripting with pythonPython is an open source language, available on thewww.python.org website. It is an extremely powerful,1MATLAB, Simulink and Stateflow are trademarks of The MathWorks,Inc.2ControlDesk is trademark of dSPACE GmbH.

object-oriented language with programming syntax andusage very similar to Basic. It has been said that pythoncan speed up development by a factor of 10 over otherprogramming languages, such as C [4]. Pythonprovides all of the control constructs and modularprogramming functionality needed for the developmentand maintenance of complex test sequences. TheControlDesk software has an integrated pythoninterpreter and a function selector tool, to make pythondevelopment as easy as possible for the user. Testscripts can be run directly, or they can also beconnected to events, including GUI events such asCommand buttons. Visteon has been able to programvery complex test sequences and make them functionalin very short periods of time.Test stimulus generationControlDesk also provides mechanisms to assist in thegeneration of test stimuli (data streams) for specific testruns. The test stimulus is generated through python,using a library designed to generate the stimuli. In orderto generate this data in real-time, software and hardwaremechanisms have been built into ControlDesk and thedSPACE hardware, which allows for full fidelity ofstimulus generation, with time based events guaranteedto occur during testing. A sequence generator tool isincluded with ControlDesk, which allows for interactivegraphical user design of test stimuli. The sequencegenerator is based on time tags and specific functiontypes, which can be combined in different manners.There are also control constructs, which allow for easylooping and conditional execution of the data streams.The tool also assists the user by providing a pregenerationof the data, for verification prior to the test,and then it provides the functions to allow the user tomap the data to model variables and execute thestimulus both interactively and within test sequences.Another feature of the Sequence generator is thecapability to playback recorded data streams, capturedduring either simulations or actual test runs. Thiscapability has been used very effectively by Visteon tosimulate drive cycles and control specific testsequences. Any data waveform stored in a predesignedMAT file format can be used for this purpose.The dSPACE hardware and software systems providethe automatic buffering and interpolation processes thatallow for real-time data playback during simulation runs.Using test stimulus to control test execution is anexample of a data-driven system. This has manyadvantages over a model driven system, in that changesin the data streams do not require model changes andprovide greater flexibility in the modeling process. Themodels are simpler to design with less real-timeoverhead, and this also allows for using the samemodels for both offline simulation and real-time testing.Advanced test scripting capabilitiesControlDesk Test Automation provides libraries offunctions for controlling the user interface andControlDesk environment. It also has a MacroRecorder, which gives the user an easy method forcapturing testing sequences performed through the GUI.The Macro Recorder saves these captured sequencesas python scripts, which can then be easily replayed andalso modified to extend and augment their functionality.There are interface libraries for communicationprotocols, such as RS-232 and GPIB, which allow forinterfacing to external devices and systems. Librariesare also provided to allow for report generation and datacapture into several windows COM OLE programs, suchas Word and Excel. Finally, sets of functions areincluded which allow the user to access and controldiagnostic devices and calibration tools, using eitherstandard protocols or the ASAP/MCD standards [3].Future pathPython is an extremely powerful tool and can be used todo every one of the tasks required for test automation.Visteon has had a successful experience with the use oftest automation because of this. The next step in thefuture involves using a new 4GL testing system fromdSPACE, called AutomationDesk, which is based ongraphically designing test sequences. The system is stillbased on python, but it eases the development andmaintenance process by providing a more intuitivegraphical design environment, as opposed to writingcode scripts. It is not a code generator, but insteadgenerates testing process objects from clearly definedtest system classes. AutomationDesk also provides avery powerful test management functionality, whichallows for more robust management of all of the facetsof a test. These include the scripts, models, test data,test results, stimulus and parameter data, etc. [5].FAILURE INSERTION AND CLOSING THE LOOPGeneral overviewIn order to fully test a PCM, the PCM must be connectedto hardware interfaces that simulate the real plantenvironment as closely as possible. The PCM isgenerally designed to test these interfaces for anyfailures, such as short circuits, missing sensors, etc, atwhich time the PCM will store a diagnostic code in itsmemory. A large percentage of the actual code in aproduction PCM is for diagnostics. If one of thesefailures occurs, the PCM software is designed to recoverfrom this failure and ensure the safety of the passengersand the environment. The dSPACE HIL systemprovides a configurable set of relays in a FailureInsertion Unit (FIU), which can be commanded tosimulate these failures. A failure for a PCM input cangenerally be simulated in software and standardhardware. By sending a 0, 5 or vehicle battery voltage

input from simulated sensor different types of sensorfailure can be simulated. To simulate failures for PCMoutputs, however, this involves using electronic relays toprovide open circuits, short circuits to battery voltage orground, or even pin-to-pin short circuits. In addition,PCM outputs generally expect to have a specific loadattached, and failures are triggered if this is not the case.process [6]. This allows for the following standard testsequence:1. Place PCM in desired performance state2. Inject a failure3. Evaluate the PCM performance during the faultcondition4. Debrief the diagnostics tool to determine if the faultwas properly detected5. Reset the fault codes to allow for further testingThe above test sequence is fully repeatable and byusing it, full lights-out testing sequences are possible.All of the diagnostic codes for a PCM may be evaluatedin a single test run (with a combination of sequences)and a complete test report will be automaticallygenerated to record the results. Once this process isimplemented, the daunting task of test regression foriterative software releases is easily contained.BENEFITS – HIL IN EVERY DEVELOPMENTALPHASEFigure 4 Failure Insertion Unit Block DiagramTest scripting interfaceThe control of the FIU system is done using a pythonlibrary in the test automation environment. A PCMoutput channel is wired to a HIL load interface, but first itis routed through a FIU channel (See Figure 4). Thisallows for exposing the channel to the failures neededfor testing. The dSPACE FIU interface is based on aserial communications protocol, which can becommanded directly from the Host PC. Simple functioncalls are used in order to control a particular FIUchannel, which eliminates the need for the user to learnthe details of the FIU serial communication protocol.With our experience during the developmental andimplementation stages of the HIL systems we foundseveral advantages of using HIL systems in testing andvalidating our software product. Although, the initialscope for using the HIL system was limited, we now usethe system in every phase of the PCM softwaredevelopment process. Figure 5 illustrates the SystemEngineering V with the phases of software developmentand highlights how HIL is being used in every stage ofthe software development.Integration of diagnostic tools for closed loop testingIt is sometimes enough to simulate failures duringtesting only for the analysis of the effects on systemperformance. However, in order to fully read systemdiagnostics and also reset the error conditions, it isnecessary to connect a diagnostic tester/device. Thisdevice is used to debrief the error codes registered inthe PCM following any diagnostic error and report thesecodes back to the tester. The python test automationlibraries also include functions to interface to and controlthese diagnostic devices. These testers generally use astandard serial or CAN-based protocol for interfacing tothe PCM. Others utilize the ASAM/MCD standard forexternal operation of the device. By providing thecapabilities for controlling these diagnostic tools,ControlDesk can fully close the loop on the testingFigure 5 HIL used in every step of developmentcycle.Broadly, the HIL applications for PCM testing in thedesign phase can be classified as Open Loop Testing(OLT) and Closed-Loop Testing (CLT). In the OLT a

simpler I/O model is used with no feedback from theplant model, as shown in Figure 6. In the OLT the inputsare not dependant of the outputs of the system. Theyare independent of each other, and consequentially thedynamic behavior of the system cannot be tested inOLT. In OLT a set of values for inputs are provided tothe system and the output responses of the systems aremonitored and recorded.vehicle speed is monitored and the throttle and brakecommand are changed manually or using an automaticdriver controller model. Closed loop simulation is wellsuited for system level testing and verification. In thefollowing sections these applications of HIL arediscussed in detail.EXECUTABLE I/O TESTING USING OLTImplementationDevelopment of Low-Level Input/Output Driver (LLD)software is one of the early phases of PCM softwaredevelopment. The LLD is implemented on top of theReal Time Operating System (RTOS). The LLD softwareis the interface between the PCM Hardware and/or HighLevel Driver Software and/or the application software.The LLD software is a fundamental piece of software inorder for the PCM application software to work properlywith the system hardware.Figure 6 Open Loop Testing in HILIn OLT the performance of the system software,actuators commands or outputs from the PCM aremonitored and verified, while feeding a predefined set ofvalues of sensor data to the PCM. OLT is applicable tocheck the PCM I/O, low-level drivers, unit testing andsome integration testing. On the other hand, the CLTrequires a complete plant model with appropriatefeedback response for the system as shown in Figure 7.In a CLT environment the PCM commanded values areused to run the actuator plant models. The actuator plantmodel output is in mechanical or electrical units and isfurther used in the plant model to compute the plantbehavior and dynamic sensor responses.Figure 7 Closed Loop Testing in HILIn the CLT environment the controller feedback loop ispreserved, and thus a complete system verification andvalidation is possible in this environment. A simple drivermodel is used to drive the vehicle simulation whereTraditionally, testing of the LLD software is done on whatis referred to as a static test bench. The input to thehardware is provided from a power supply and/or asignal generator and the outputs of the hardware aremonitored with a chart recorder and/or an oscilloscope.An early phase of automated testing of LLD softwarewas implemented by a skeleton executable softwarelayer developed on top of the LLD software layer; henceit is called the “Executable I/O (EIO) software”.The different layers of the EIO software and the HILsystem interface block diagram are illustrated in Figure8. The executable layer is implemented in two levelstructures, the first is the communication layer and otheris the command layer. The communication layerinterfaces with the user and the command layerexercises the LLD software to manipulate the hardwareI/O. The communication layer of the EIO software isintegrated with the HIL communication layer, and theHIL becomes the server and the EIO software becomesthe client. A sequence of tests is developed to exercisethe complete range of all I/O. The HIL system Inputdrivers command the EIO software to provide acomplete range of valid as well as invalid values tooutput drivers. The HIL system co-ordinates the dataplayback and data capture simultaneously to completelyautomate testing of LLD software. This EIO softwareimplementation provided the capability of testing the LLDsoftware with test points over a range of the inputs andoutputs.Prior to the integration of HIL with the EIO testing, themanual mode of testing was only capable of using a verylimited set of data points, which was not exhaustingenough to completely test the entire range of thehardware I/O. This manual method of testing was shownto be both time consuming and error prone. Using HIL

technology for the EIO software testing the complete I/Orange can be tested automatically.on a target. Utilization of test scripting and test stimulusgeneration technique the HIL system provided somelevel of dynamic input to the system, rather than just astatic set of input values.Figure 8 HIL integration of Executable I/O TestingThis implementation of HIL integrated EIO softwaresignificantly reduced the testing time of all PCM I/Os,and provided a far more complete range of every test aswell. In later applications, using this testing very early inthe development phase flagged some discrepanciesbetween the requirements, the specifications and thesoftware implementation. By discovering thesediscrepancies at this early phase, significant resourceswere saved, compared to finding these discrepancieslater in the development cycle.UNIT LEVEL TESTING USING OLTThe next level of testing phase is Unit Level Testing(ULT) of application software. ULT is a derivative ofOLT. The Powertrain application software consists ofmultiple interdependent features, and each featurecontains different level of sub-features. The featuresand sub-features of application software are defined byfunctional boundaries. The features and sub-featuresare developed based on the Powertrain requirements.The features and sub-features are tested against suchdefined requirements. In ULT one piece or one unit ofsoftware defined by certain functional boundaries istested. For ULT, sets of inputs are designed to exercisethe specific unit of software and fed into the PCM, andthe output from that specific piece of software ismonitored and recorded. The outputs of the softwareare checked against the requirements for the softwaregiven that set of inputs. Traditionally, the ULT is amanual operation using tools like a software debuggerand manually stepping through software code to checkthe values of the outputs of the software, as well usingtools like an oscilloscopes and chart recorders to recordoutputs from the PCM. The HIL integration of the ULTprovided a more methodical way of completing unit testFigure 9 Open Loop PCM Application TestingINTEGRATION TESTING USING OLTOnce, sets of ULTs are completed, the next obviousstep is to recombine these units and test on a subintegration level. The integration of features is testedusing the OLT methodology to test the interactionbetween several features. In the sub-integration level thecomplete software is not integrated with all the requiredfeatures, but a few closely related features areintegrated as a broad feature. In this test environmentthe feature level inputs are provided from the HIL systemas dynamic inputs, and the outputs from the subintegrationlevel are monitored and recorded. Eventhough the input values may have some dynamicbehavior in it, the absence of dynamic plant modelprevented it from running in closed loop environment.The dynamic inputs were not based on the systemresponse output; rather it was a coherent set of inputdata. Refer to Figure 9 for a block diagram of open loopintegration testing. The next natural progression oftesting is the verification of the complete feature inClosed Loop.PROGRESSION FROM OPEN LOOP VERIFICATIONTO CLOSED LOOP VERIFICATIONIn the OLT methodology of verification, the inputs to thePCM are provided during the simulation, and theactuator outputs from the PCM are monitored. Thecontrol loop feedback mechanism is not in place so thedynamic response of the PCM software cannot be testedin OLT. CLT testing is necessary in order to fully validatethe functionally of the PCM.

Figure 10 Closed Loop PCM Application Testing.Figure 11 Closed Loop Plant Model.SYSTEM LEVEL TESTING USING CLTThe components of system level testing using CLT areillustrated in Figure 10. The fundamental differencebetween the OLT and CLT is the presence of dynamicplant model in the CLT system running in real timesimulation. The plant models represent the bahavior ofthe actual plant and provide appropriate feedbackresponse. The response of the plant model influencesthe input to the system, thus providing a completedynamic system simulation with controller feedback looppreserved. Figure 11 shows a block diagramrepresentation of Open and Closed loop testinginterfaces of the HIL system with the PCM. The“Ambient_and_Environment” block contains static inputssuch as atmospheric pressure and temperature; the“Driver_Inputs” block contains a manual and automaticdriver model. The automatic driver model compares thevehicle speed feedback with the speed stimulus anddecides the required throttle and brake inputs to theplant model, while manual driver provides the hooks tocontrol the brake and throttle pedal input from externalsource under simulation environment.The “PCM_Interface” block contains the routing of I/Osignals between a specific family of PCM and the HILsystem hardware. The "Vehicle Model" contains theactual plant model representing the dynamic behavior ofthe plant, for our application it is a combination of andengine and transmission model. We have implementeda complete set of sensors, actuators and plant models inthis system. In order to be able to simulate in real time,we used a regression based engine model, usingmapping data for the same engine from a Dynamometer.Simplified transmission, driveline and vehicle modelswere also implemented. After successful simulation ofKey On Engine Off (KOEO) and Key On Engine Running(KOER) conditions, the system was successfully testedand simulated for idle conditions, followed by manualand automatic drive cycle simulation implementation.Prior to integration of the plant models with the HILsystems, the plant models were simulated and validatedon the desktop. After validation of the plant model in thedesktop environment the models were integrated withthe HIL system. In order to validate the plant models theresults obtained from a real engine drive cycle testconducted on a Dynamometer were compared with thesimulation results. In drive cycle exercise the vehicle isdriven through a known speed profile (e.g. FTP UDDS).The target speed is input to the automatic driver model.The automatic driver receives the actual speed of thevehicle as a feed back from the complete vehicle plantmodel. The automatic driver manipulates the brake andthrottle to keep the vehicle in targeted speed. Thevehicle speed profile from the Dynamometer test cellrecording (using calibration tool, ATI Vision 1.9) 3wasused as the input stimulus for the automatic driver forthe simulation. Engine torque, engine speed and vehiclespeed from the simulation are recorded usingControlDesk, the HIL user interface software, and thedata was compared. The comparison (not presented inthis paper) of the vehicle and engine speed profile andengine torque values along with other variables showeda very good correlation with minimal error. Themaximum errors in these comparisons were less than 10percent. Although final software verification andvalidation can be done only on a real vehicle, thecomplete closed loop simulation can easily be used forvalidating software at a system level during the earlydesign stages of software development with less than 10percent error margin to validate the PCM software.There are certain limitations in using HIL for validationand verification of PCM software due to high3ATI is trademark of Accurate Technologies Inc.

computational requirements for a real-time simulation.For example the emission related testing and validationis not feasible in the current HIL environment. A betterplant model (e.g. complete detail combustion basedmodel), however, can provide better correlation ofengine variables as well engine performance. However,a detailed combustion based model may not be suitablefor real time execution with the present computingtechnology.Future advancement, both in real-time computing andplant modeling will close this gap of complete bench topsimulation and may make the HIL an absolutereplacement for a real vehicle for software validation andverification.CONCLUSIONA brief discussion of on the implementation and usagescenario of HIL systems at Visteon Corporation for PCMsoftware verification and validation is presented in thispaper. The Powertrain Software development group inVisteon uses HIL systems in every step of the softwaredevelopmental phase.Using HIL in integrated EIO software, Unit Testing, andclosed loop testing of the system software significantlyreduced the testing time and improved software quality.Software quality is improved by identifying potentialerrors and/or discrepancies between the requirement,specification and software very early in the developmentphase.The successful implementation of closed loop simulationhas proved to be useful in validating several features atthe system level. However, further improvements in realtime computing technology and implementation will berequired for simulating features such as emissionrequirements.REFERENCES1. H. Hanselmann, "Hardware-in-the-Loop SimulationTesting and its Integration into a CACSD Toolset",IEEE International Symposium on Computer-AidedControl System Design 1996.2. Hanselmann, H.: Advances in Desktop Hardware-Inthe-LoopSimulation. SAE Paper 970932, 1997.3. S. Nabi, "Development of an Integrated TestEnvironment for ECU Software Validation," dSPACEUser Conference 2002,4. Eckel, B.; "Design Patterns In Python", 2002Software Development West conference, San Jose,CA, USA.5. Lamberg, K.; Richert, J.; Rasche, R.; A NewEnvironment for Integrated Development andManagement of ECU Tests, SAE 2003-01-1024,Detroit, USA.6. Gehring, J.; Schuette, H.; A Hardware-in-the-LoopTest Bench for the Validation of Complex ECUNetworks, SAE 2002-01-0801, Detroit, USACONTACTSyed NabiVisteon CorporationVisteon Technical Center17000 Rotunda Dr.Dearborn, MI 48121Phone: (313) 755-1881E-mail: snabi@visteon.comMahesh Balike, PhDVisteon CorporationVisteon Technical Center17000 Rotunda Dr.Dearborn, MI 48121Phone: (313) 755-3804E-mail: mbalike@visteon.comJace AllenSenior Project EngineerApplications GroupdSPACE, Inc.28700 Cabot DriveSuite 1100Novi, MI 48377Phone: (248) 567-1265Fax: (248) 567-0130E-mail: jallen@dspaceinc.comKevin RzemienSupervisorApplications GroupdSPACE, Inc.28700 Cabot DriveSuite 1100Novi, MI 48377Phone: (248) 567-1265Fax: (248) 567-0130E-mail: krzemien@dspaceinc.comADDITIONAL SOURCES1. R.W. Weeks and J.J. Moskwa, "Automotive EngineModeling for Real-Time Control UsingMATLAB/SIMULINK", SAE paper 950417.2. H. Hanselmann, "Hardware-in-the-Loop SimulationTesting and its Integration into a CACSD Toolset",

IEEE International Symposium on Computer-AidedControl System Design 1996.3. S. Raman, N. Sivashankar, W. Milam, W. Stuart andS. Nabi, "Design and implementation of HILsimulators for powertrain control system softwaredevelopment," Proceedings of the American ControlConference, pp. 709-713, 1999.4. N. Sivashankar and K. Butts, "A ModelingEnvironment for Production Powertrain ControllerDevelopment," Proceedings of IEEE CCA/CACSD,session CACSD-563, 1999.DEFINITIONS, ACRONYMS, ABBREVIATIONSCANCLTController Area NetworkClosed Loop TestingDUT Device Under TestECU Engine Control UnitEIO Executable I/O SoftwareFIU Fault Insertion UnitFTP Federal Test ProcedureHIL Hardware-In-The-LoopHW HardwareI/O Input/OutputLLD Low Level Driver SoftwareMBD Model Based DevelopmentOBD On Board DiagnosticsOEM Original Equipment ManufacturerOLT Open Loop TestingPCM Powertrain Control ModuleRTOS Real Time Operating SystemUDDS Urban Dynamometer Driving ScheduleULT Unit Level Testing