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

More documents

Recommendations

Info

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.
Page 1 and 2: SAE TECHNICALPAPER SERIES 2004-01-1
Page 3 and 4: 2004-01-1240An Overview of Hardware
Page 5 and 6: emote control power supply. The pow
Page 7: input from simulated sensor differe
Page 11 and 12: computational requirements for a re

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

Create successful ePaper yourself

Delete template?

Save as template?