an investigation into the use of hardware-in-the-loop simulation testing for automotive electronic...

*Corresponding author. Tel.: #44(0)24-7621-4804.

Control Engineering Practice 7 (1999) 1343}1356

An investigation into the use of hardware-in-the-loop simulationtesting for automotive electronic control systems

I.R. Kendall!,*, R.P. Jones"!Electrical/Electronic Engineering Center, Jaguar Cars Ltd., Whitley, Abbey Road, Coventry, UK

"School of Engineering, The University of Warwick, Coventry, UK

Received 21 October 1998; accepted 14 June 1999

Abstract

This paper describes a project to demonstrate the practicality of real-time hardware-in-the-loop simulation testing (HILST) asa technique for the development of automotive electronic control systems. It covers the development of the plant model o!-line, plusa discussion of the steps involved in converting the model to run in real-time, and interfacing it with actual vehicle hardware. ( 1999Elsevier Science Ltd. All rights reserved.

Keywords: Hardware-in-the-loop; Simulation; Testing; Automotive electronic systems

1. Introduction

The automotive business is one of the most competi-tive and global industries in existence. Car buyers expecthigher levels of quality, safety and functionality, and thisis compounded by ever-downward pressure on costs andtime. As part of Ford, Jaguar is embracing a new `masterplana for vehicle development, called the Ford productdevelopment system, or FPDS. FPDS is one of Ford'smajor world-wide initiatives that aims to strengthen theCorporation's position in the competitive automotivemarketplace. The main themes of FPDS are a dramaticshortening of time-to-market, a reduction in develop-ment costs, and greater customer perception of productquality and value. One of the key mechanisms for achiev-ing these goals is the aggressive use of modelling, simula-tion and analysis, in order to facilitate greater iterationand exploration of the properties of a design beforecommitting it to volume production.

Most of the systems within a modern car, ranging fromthe engine to the door locks, now involve some form ofembedded electronic control. Within Jaguar, the detaileddesign of all the electronic control systems is performedby carefully selected automotive suppliers from all overthe world, with Jaguar acting as the overall system speci-

"ers, integrators and validators. The current develop-ment process at Jaguar o!ers very little in the way ofanalytical techniques to the application of control sys-tems, relying instead on the practical approach of build-ing prototype vehicles, which are then comprehensivelyand exhaustively tested, calibrated and tuned. This ap-proach is e!ective and has served its purpose very wellsince the introduction of electronics into cars about twodecades ago. It's success depends on the skill of experi-enced engineers, who understand the practical issues ofthe systems with which they are dealing, and importantly,also understand the expectations of Jaguar customers.

However, building #eets of prototype cars is expensive,resource intensive and time consuming. Each prototypecar is carefully hand built, and there are always problemsprocuring new prototype parts. Once testing begins,every time an issue is found, it must be communicated tothe supplier, design changes made to hardware or soft-ware, new parts procured, "tted and then re-tested. Thistakes precious time and resources. Furthermore, it isa recurring problem to co-ordinate the re-working of#eets of dozens of prototype cars to the latest level ofparts. Invariably, much of the testing in the early stagesof the programme will be ine!ective, as many of the partswill be unrepresentative or even completely unavailable.

FPDS is challenging this working practice in twoways. Firstly, there is unlikely to be enough time forsuccessful development based on vehicle-level `build-test-build-testa iteration; and secondly, a vehicle

0967-0661/99/$ - see front matter ( 1999 Elsevier Science Ltd. All rights reserved.PII: S 0 9 6 7 - 0 6 6 1 ( 9 9 ) 0 0 1 0 3 - 3

programme planned under FPDS will simply not makeprovision for anywhere near as many prototype cars aswere possible under the previous project planning frame-work. These factors, coupled with demands for deliveringhigher levels of quality at lower costs, leads to interest inany new processes that may assist in meeting the chal-lenges. One such possibility is hardware-in-the-loopsimulation testing (HILST) (Hanselmann, 1993).

HILST is a technique whereby real control systemscan be exercised against simulations of the plant-under-control, in this case a car, or part of a car, thus replacingmany aspects of traditional vehicle testing (Hanselmann,1996). This reduces dependence on prototype vehicles,especially in the early stages of a programme, and there-fore reduces the time, e!ort and resources required tobuild and support them. Ultimately, the objective is to beable to build the "rst full prototype car much later ina development programme, and in such a way that itdoes not require major modi"cation before going intovolume production.

Working with HILST should include both the capabil-ity to model the system entirely as a simulation * theso-called ò!-linea or `pure simulationa * as well asbeing able to use real components running against simula-tions of others òn-linea, or `hardware-in-the-loopa (HIL).Ò!-linea simulation will normally take place before mov-ing onto òn-linea, HIL simulation. The o!-line simula-tion must be constructed with the underlying objective ofdeveloping it later into an on-line HIL simulation.

This raises several questions. Can simulation andHILST ever truly replace the testing of real cars? Whichtools are needed? How can existing processes and engi-neers' skills be adapted to include simulation andHILST?

The approach Jaguar decided on to answer such ques-tions was to carry out a pilot project, with the followingobjectives:

f to try out the selected tools;f to show that it can be done, and to understand the

realistic capabilities;f to get a feel for how long it takes, and how HILST can

be implemented;f to understand and solve the key technical issues;f to look for additional bene"ts not currently known

about;f to understand likely set-up costs and training needs.

The main goal was to evaluate the process and thetools, and not to develop a vehicle control system. There-fore it was appropriate to base the pilot study on anexisting control system (i.e. one already in production),one that was already validated, and one that was notprohibitively complex within the time available. A suit-able candidate was the driver's door control subsystemfrom Jaguar's 1997 Model Year XK8 sports car, whichhas a small electronic module embedded in each door.

This is a novel application of simulation and HILSTtools, because this type of system has traditionally notbeen thought of in control engineering terms. Most pub-lished examples are applications such as engine control,e.g. Weeks and Moskwa (1995), Dorey and Maclay (1996)and vehicle dynamics, e.g. Potter, Cherry and Jones(1996), DePoyster, Hoyling and Majeed (1996).

Jaguar has elected to base its present simulation activ-ities around the MATLABt/SIMULINKt tools fromThe Mathworks Inc. These tools are widely used inindustry and academia, and o!er a capable, cost-e!ectivesimulation solution. However, it is the existence of a newMathworks tool, called STATEFLOWt, which workswithin the SIMULINKt environment, that is one ofthe major attractions. STATEFLOWt enables statetransition, `mode-switchinga-type behaviour to be integ-rated with the continuous and discrete time representa-tions traditionally provided by SIMULINKt. This hadnot been possible until recently, and has been a seriouslimitation on how faithfully systems could be modelled,as most real control systems involve multiple modes andsystem operational states. The HILST platform selectedis supplied by dSPACE GmbH of Germany. dSPACEo!er a modular real-time computing environment, withcon"gurable I/O capability for bringing the simulatedsignals into the real-world, and a set of software toolswhich integrate strongly with the MATLABt products.

This paper describes some of the technical work per-formed by Jaguar (in conjunction with Cambridge Con-trol Ltd.) during the pilot project to develop an o!-linesimulation of the XK8 driver's door system and to devel-op it into a HILST demonstration using an actual con-trol module.

2. The Jaguar XK8 body control systemand driver's door module (DDM)

The driver's door module, or DDM, on the XK8 is oneof seven electronic control modules that are multiplexedtogether on a serial data communications bus, togetherforming what Jaguar calls the `body control systema(Ross and Savage, 1996). The full body control systemconsists of a module in each door (one of which is theDDM), a module under each seat, the instrument clusterand two further modules at the front and rear of thevehicle, see Fig. 1. Functions are distributed betweenthese seven modules, using an SCP bus to pass informa-tion between them. SCP is a multi-master multiplexprotocol that transmits data at a rate of 41.7 kbps, usingpulse width modulation, over a twisted pair bus (SAE,1995). The partitioning of the functionality between the7-body control system modules depends on several fac-tors, such as the provision of suitable I/O, reductionof wiring runs, processing capacity and failure-modemanagement.

1344 I.R. Kendall, R.P. Jones / Control Engineering Practice 7 (1999) 1343}1356

Fig. 1. The XK8 body control system architecture.

The DDM essentially controls three main functions inthe driver's door: central locking, with superlocking (ordouble-locking); electric window operation, with one-shot and anti-trap functions; and electric wing mirrormovement, with memory positioning. It contains a small,low-cost 8-bit microcontroller, interfaced to 11 wiredoutputs and 22 wired inputs, and it transmits 51 SCPmessages and receives 146 SCP messages (including diag-nostic messages and requests) to and from the other sixmodules.

3. O4-line plant model development

The "rst stage was to develop an o!-line simulation.A sensible approach initially was to treat each of thethree sub-systems, i.e. locks, windows and mirrors, separ-ately as three independent pieces of `planta and `con-trola, and to integrate them together into a single-doorsystem model later on. Throughout the o!-line phase, itwas important to keep in mind that the purpose waseventually to produce an on-line simulation, with anactual DDM `in the loopa with real-time simulations ofthe `planta (locks, mirrors and windows). Therefore, itwas not necessary to attempt to produce a full model ofall the control logic of the DDM software. Instead, theDDM could be modelled at a very simple level at thisstage, only su$cient to be able to interact with the`planta. This allowed more attention to be paid to theplant models, which were required for testing againstthe real DDM. The results of the o!-line simulation,and some details of the simple DDM controller models,are presented in Kendall, Jones and Thomas (1998).

3.1. The mirror subsystem

The mirror `planta model is needed to capture thebehaviour of an electric wing mirror assembly, the keycomponent of which is the mirror actuator. This consistsof two small permanent magnet DC motors, one for thehorizontal motion of the mirror and one for the verticalmotion, each of which has a potentiometer to providea position feedback signal. The behaviour that is impor-tant to the DDM requires the model to have two inputs* the voltage applied to each mirror motor (and whichcan change polarity for driving the motor in either direc-tion), and two outputs* the voltages from the positionfeedback potentiometers. Some of the key details of oneof the motor blocks are shown in Fig. 2.

This simple model assumes that the drive voltage gen-erates a proportional torque, which can be integratedtwice to get position. Motor transients, current andback-EMF are not important functionally, thereforethese are not modelled. The only complexity is the needto have the velocity at zero when the mechanical limit isreached, even if a voltage is still applied, which isachieved by a reset function for the `velocitya integrator.

3.2. The window subsystem

The window mechanism consists of several compo-nents * a relatively powerful permanent magnet DCmotor, the window `regulatora (the gears and pivotedarm constrained by tracks, which convert the rota-tional motion of the motor into the vertical linear motionof the window), the window glass itself and the doorframe/seal. In addition, the motor includes an integrated

I.R. Kendall, R.P. Jones / Control Engineering Practice 7 (1999) 1343}1356 1345

Fig. 2. Model of the mirror dynamics.

Fig. 3. The window dynamics model.


Fig. 4. Plant model of the locking subsystem.

two-channel, Hall-e!ect, incremental position encoder.One of the key pieces of behaviour that is important forthe window system is the electrical current in the motor,which the real DDM measures to detect when somethingis trapped in the window. This time, therefore, it wasnecessary to model the e!ects of back EMF, and toinclude terms for motor coil winding resistance and in-ductance in order to get a reasonable representation ofcurrent #ow. A key di$culty was the non-linear way inwhich the friction on the window varies with its position.These non-linearities arise because of the shape of thewindow glass, which governs how much of it is in contactwith the seal at the bottom, and the e!ects of the seal asthe window reaches the top. This was modelled witha look-up table that approximates the friction into fourregions. The key details of the SIMULINKt model areshown in Fig. 3.

3.3. The lock subsystem

The main part of the plant model in this instance is thedoor latch assembly. This is quite a complex piece ofmechanical engineering, with many linkages, springs andlevers, coupled with an electrical actuator and 6 micro-switches. However, using the powerful paradigm pro-vided by STATEFLOWt, it was possible to simplify thekey behaviour down to something manageable. Thebasic approach was to separate the dynamics from the`state-transitiona functions, see Fig. 4. The dynamics arevery simple, consisting mainly of a small permanentmagnet DC motor, similar to the mirror motors de-scribed earlier, which is the core of the locking actuator.There are three drive signals, which in the `o! a state areall grounded. The latch is locked by applying a 12 Vpulse for 750 ms on the `locka input. This activates the


Fig. 5. The lock àctuatora superstate.

motor that moves a worm gear acting on the mechanism.When it reaches the lock position, a microswitch switchesthe motor terminal from the `locka input to the `super-locka input. To superlock the door latch, a further750 ms pulse is put on `superlocka input. Superlockingmoves the worm gear further along its track, which inturn moves a small plastic cam to mechanically "x theactuator in position. (This makes it impossible to unlockthe door mechanically, e.g. from the interior handle.)Unlocking is achieved by a single 12 V pulse for 750 mson the ùnlocka input from the locked or superlockedposition.

Apart from the movement of the lock motor, all theother behaviour is `state-transitiona based, and couldbe modelled using a STATEFLOWt block withinSIMULINKt that is executed every 50 ms, as shownin Fig. 4. This block contains a Harel statechart(Harel, 1987) with three concurrent and dependent super-states, representing the àctuatora, the `doora andthe `bolta.

Fig. 5 shows the actuator superstate. A locking se-quence goes through the states as follows:

f `freea, when the `bolta can be locked and unlockedmechanically with the key or with the interior handle.

f `lockinga, when the lock actuator is moving the lockdirection, i.e. a 12 V signal is present on the `lockainput.

f `lockeda, when the actuator has reached the lockposition (lock}stop), and the superlock micro-switch switches over (as described earlier). This isa sub-state of `freea as, of course, the door canbe unlocked mechanically using the interior handleor the key.

f `Superlockinga, when the actuator is in the process ofmoving to the superlock position (the worm gear mov-ing the small plastic cam), i.e. a 12 V signal is presenton the `superlocka input.

f `Superlockeda. It is now impossible to unlock the doormechanically.

f Ùnsuperlockinga, moving the cam out of position.A 12 V signal is present on the ùnlocka input and themotor is moving in the other direction.

f Ùnlockinga, as ùnsuperlockinga, except the super-lock microswitch switches back over.


Fig. 6. The lock `bolta superstate.

Fig. 7. The `doora superstate.

f Ùnlockeda, again a substate of `freea as it is possibleto mechanically lock the door.

Concurrent with the actuator, and dependent on itsstate, is the `bolta superstate. This is somewhat abstractin that there is no single actual physical componentidenti"able as the bolt, but it represents combinations ofmechanical levers and springs which physically lock thedoor. Its superstate is shown in Fig. 6. It is basicallyeither `lockeda or ùnlockeda, and it moves between thetwo by the action of the electrical actuator, the interiorhandle, or the door key. The door key barrel has twomicroswitches indicating when the key is in the lock or

unlock position, and these are used as inputs to the model(`key}locka and `key}unlocka). There are two additionalèrrora states one which enables the door to be unlockedonly via the key when the actuator is superlocked and thebattery goes #at, and another which allows for the bolt tobe locked when the door is open (lock not synchronised).There is a microswitch output that indicates whether themechanism is locked or unlocked.

The "nal superstate represents the door, as shown inFig. 7. It is either open, closed or ajar. Whether it can beopened from the closed state, depends on whether it islocked. There is a microswitch output that indicateswhether the door is fully closed or open/ajar.


Note there is a further microswitch in the door latchassembly that indicates when the exterior door handle islifted, but this is not used by the locking subsystem.

4. Integration of the subsystem models

As with most engineering problems, the approach tomodelling requires an ability to break the problem downinto smaller constituent parts that can be addressed indi-vidually. For the example described here, this is apparentin the way the windows, mirrors and locks were initiallymodelled as separate subsystems. However, it is equallyimportant that having modelled each of these individ-ually, they must then be integrated together to forma model of the whole door control system. This raisedtwo key issues.

Firstly, whilst the three sub-functions, windows, mir-rors and locks, could be regarded as separate for thepurposes of developing the plant models, to completea model of the system as a whole it was not just a case ofputting the three together. There was a signi"cantamount of additional functionality which `falls throughthe cracksa when treating the main sub-functions separ-ately. This comes from the interactions of the sub-func-tions with each other and, more signi"cantly, with therest of the vehicle. For example, the door lock controlcannot be fully described by the driver's door alone, asthe vehicle has central locking which must depend on thepassenger's door too. Furthermore, the control for thecentral locking is distributed across several modules onthe body system SCP network, and therefore the DDMcannot be understood without modelling the interactionswith three of the other "ve modules, the passenger's doormodule (PDM), the body processor module (BPM) andthe security and locking module (SLM). Each of theseexchanges messages over the SCP network to producethe required system functionality. It is interesting thatthis approach seems to be more complex than necessary,but the functionality is deliberately distributed for addedsecurity, i.e. it is impossible to defeat the locking systemby tampering with any one module. Modelling the be-haviour of the SCP message tra$c that relates to thedriver's door system proved to be tricky, not least be-cause of the large number of connections that needed tobe multiplexed and de-multiplexed within SIMULINKt.With larger mux/demux blocks it became increasinglydi$cult to keep track of the order in which signals arevectorised, and great care was required to ensure that theordering was correct. It is expected that this concern willbe addressed in a future release of SIMULINKt by theintroduction of a new bus block, from which all thevectorised signals can be referenced by name instead ofsequence order.

Secondly, it is not possible simply to join three separ-ately developed sub-function models together, at least

not without breaking them down to low-level blocks thatare then e!ectively used to build a new model from thebottom up. This is a problem that would be a funda-mental issue in a team where several individuals areworking on di!erent parts of the same model. If notaddressed, it would result in di$culties in bringing thework together into a larger single model. One solution isto have some common, generic structure, into which allthe individual models must "t, i.e. collecting the low-levelblocks into sensible groups. It should then be much easierto take the groups of similar blocks and combine themwith mux/demuxs in a recursive manner. Fig. 8 shows thestructure of the model adopted here. Both the wholesystem and each of the three subsystems have a verysimilar structure. The combined model could then be puttogether more easily, for example by grouping the threesubsystem `test inputsa blocks inside the single `testinputsa block at the top level.

5. The development of the real-time simulationand HILST system

Once the plant models were satisfactorily developedo!-line, the "rst step in moving towards a real-timesimulation was the selection of a simple "rst-order,"xed-step integration algorithm (Euler), instead of theSIMULINKt default variable step algorithm used untilnow. A one millisecond "xed-step size was selected. Atthe "rst attempt, it was found that some parts of themodel became numerically unstable, the o!ending por-tion being the window motor dynamics. This problemwas corrected by adjusting the window motor para-meters, and, when adjusted further to match measureddata, the instability did not occur again. Hence, it wasconcluded that except for a slight loss of integrationaccuracy, the simulation should perform well in the real-time environment.

One of the key steps in modifying the model itselftowards a real-time HILST implementation was the def-inition of the signals that must be passed to and from thereal DDM via dSPACE I/O boards. This was a relativelysimple task in principle, although one which was com-plicated by the need to fully understand the voltages,currents and loads associated with each pin on theDDM. For example, whether a switch input is active highor active low, to 12 or 5 V. It was at this point that theproblem of how to interface the dSPACE system becameprevalent, i.e. interfacing dSPACE's TTL digital andlow-current analogue signal levels, to an automotiveenvironment requiring high currents and 12 V. The solu-tion was to construct an interface and signal-condition-ing unit that can provide the real-world signals to theDDM and can bu!er the signals to the dSPACE system.This interface unit was further speci"ed to include theso-called controllable loads. These allow an analogue


Fig. 8. The overall o!-line-model structure.

voltage from the dSPACE system to control the currentdraw from the DDM up to a maximum of 20 A. This isan important feature because the DDM measures actualwindow motor current to achieve the anti-trap function.In all, the interface unit built for this application consis-ted of two such controllable loads, plus: four bu!ereddigital inputs and simple loads (from the DDM); 19bu!ered digital outputs (to the DDM); two analogueinputs with gains of 0.625 (16 V at the DDM gives 10 Vto dSPACE); and three analogue outputs with gains ofa 1.6 (10 V from dSPACE gives 16 V at the DDM).

In addition to the electrical signals, the real-time pro-gram must also have the ability to send and receive SCPmessages between the simulation and the real DDM. Noo!-the-shelf solution was available from dSPACE (asSCP is proprietary to Ford), therefore it was necessary tohave special hardware and software developed for thisproject. This became a small project in its own right, andone that puts the #exibility of the dSPACE platform andMathworks software to the test. The solution was arrivedat using the dSPACE prototyping board and the targetlanguage compiler facility within SIMULINKt. This

provided a very neat and easy to use interface in which allthe messages to be received and transmitted are de"nedwithin a standard spreadsheet. This is important to en-sure that other Jaguar engineers, who may not havemuch software expertise, are able to work with the sys-tem in future applications. It is also worth mentioningthat making the hardware-in-the-loop system capable ofreplacing all the SCP messages to and from the otherbody system modules, places a restraint on the con"gura-tion of the SCP network itself. Within SCP, messages are`stampeda with the physical address of the transmittingmodule. As there are seven body modules on XK8, andonly one SCP board in the dSPACE system (with onlyone physical address), it is important that the receivingmodule does not use the physical address. It is fortunatethat in the implementation of SCP used on XK8, Jaguarhas only speci"ed the so-called `broadcast modea mess-ages that do not use the physical address. If HILST is tobe widely adopted, this will need to be a design constrainton the SCP network for future applications.

A further complication arose with the message `re-questa facility that is also a part of SCP. However,


Fig. 9. SCP transmission for the inertia switch signal.

this problem was solved relatively easily withinSIMULINKt. Fig. 9 shows the SIMULINKt model forthe ìnertia switcha signal which needs to be transmittedas an SCP message on the transition from o!-to-on oron-to-o!, and when requested to do so upon receipt ofa request message. Two SCP messages are de"ned, onefor àctivea and one for ìnactivea. A transmission ofthe appropriate one is triggered by a rising edge ofthe corresponding SIMULINKt signal.

Fig. 10 shows the overall top-level of the model once ithad been adapted for real-time HILST application, andtogether with some detail of the blocks required for thedSPACE and SCP interfacing. Compare this with Fig. 8.The `test inputsa and `simulated window-mirror-lockablocks are essentially the same as in the o!-linesimulation.

The "nal step necessary to complete the hardware-in-the-loop demonstration was to consider mechanisms forenabling the user to interact with the real-time program.dSPACE provide a software tool, called Cockpitt, forexactly this purpose. Cockpitt allows the user to tapdirectly into the parameters and signals of the real-timeprogramme from an o!-line PC, without interrupting thesimulation. Therefore, each of the switches and inputevents needs to be represented. Furthermore, it is alsopossible to represent outputs from the model, such aswindow and mirror position, as bar displays within thesame window. Fig. 11 shows a screen shot of Cockpittfor the DDM HILST implementation.

6. Results

Once the model and its interfaces were developedwithin SIMULINKt, it was a straightforward task tobuild the real-time code and download it to the dSPACEsystem, as the whole process is handled automatically by

a `makea "le. With the real-time program running on thedSPACE hardware (a 1 ms simulation step size ona TMS320C40 DSP processor board executes in around350 ls), connected to the real DDM via the interface unitmentioned earlier, it was possible to exercise the func-tionality of the DDM. For example, using the mouse toclick on the driver's window down button in Cockpitt,the DDM will activate the window motor drive signal,which would in turn be responded to by the model andthe simulated window moves down. Note how the con-trollable load within the interface unit pro"les the win-dow motor current as shown in Fig. 12. These data weretaken using another dSPACE software tool designed fordata acquisition from the real-time simulation, calledTracet. In addition, the mirror sensor signals and thelocking actuator responses are presented in Figs. 13 and14. Hence, it can be seen that this gives the ability to fullytest the functionality of the DDM without requiring theother body system modules or a vehicle. This was themain objective of the pilot study, i.e. the ability to dynam-ically test a software-based control unit without requir-ing any additional hardware, either in the form ofcomponents or an actual prototype vehicle.

Furthermore, another software tool from dSPACE(MLibt) allows a fully automated test script to be writ-ten, removing even the need for the user to drive Cock-pitt. Once such a test script is constructed, it is possibleto repeat tests and report results automatically, thussaving time and allowing more consistent and rigoroustesting throughout. For the HILST pilot study using theDDM described here, this was successfully demonstratedby coding up a small portion of the actual test plan forthe XK8 relating to the door functions. It is possible fromthis point to go on and code up all of the test cases for thewhole of the driver's door system. (The test cases themsel-ves are usually de"ned by the system design engineerfrom the system functional speci"cation, and is outside


Fig

.10.

The

real

-tim

em

odel

stru

cture

and

the

I/O

inte

rfac

e.


Fig. 11. The cockpitt screen for the DDM HILST application.

Fig. 12. HIL window motor current.


Fig. 13. Mirror sensor outputs.

Fig. 14. Lock signals and outputs.

the scope of this paper.) Following the same principles,and dealing systematically with each control system sep-arately in isolation from the vehicle, it is possible to carryout full functional validation tests for all the controlsoftware. This facilitates a focussed e!ort on the systemof interest without unwelcome complications from other,unrelated systems which can occur on prototype cars. Inaddition, this has the advantage that each control system,although treated separately, can be validated againsta known baseline, and in a controlled and repeatablefashion.

7. Conclusions

The purpose of this work was to better understand thesimulation process, and to investigate whether hard-ware-in-the-loop-simulation-testing really can help Jag-uar achieve aggressive new product development timing.Some of the most valuable experience gained from thispilot study is the need for a systematic approach tosimulation. However, given such a systematic process,Jaguar has the potential to be able to improve on thequality of the work performed, allowing that work to be


done earlier, at a greater level of understanding, andreducing the costs by decreasing dependence on vehicletesting.

It has been demonstrated that it is possible to buildsensible and representative plant models of the doorsystem that are capable of real-time execution with rela-tive ease. The driver's door system was selected for itsapparent simplicity, however it has demonstrated thepower of combining state-transition behaviour (e.g. Fig.5) and continuous time dynamics (e.g. Fig. 3) in a singlemodel. This has provided con"dence in the capabilityand #exibility of the chosen MATLABt/SIMULINKt/STATEFLOWt tools. As a result of completing this pilotstudy, Jaguar have been able to identify how the role ofthis type of simulation can "t within the FPDS vehicledevelopment process, to save time and money, and im-prove the e!ectiveness of engineering new electronic con-trol systems. Furthermore, training and budgetary needshave been established to implement these methods aspart of FPDS for Jaguar's new vehicle programmes.

The evidence is that hardware-in-the-loop simulationcan make a di!erence, especially when it is used forautomated testing of complex software-based embeddedcontrol units. In addition, the necessary "rst step ofdeveloping and analysing o!-line, or `purea simulationmodels forces a better understanding of the systemsmuch earlier in a programme, and before any hardwareneeds to exist. There are undoubtedly many challengesahead, both technical (e.g. generating a complete set of`planta models for the vehicle and its systems, and inter-facing to more control units), and non-technical (e.g.changing the current skill base of the majority of auto-motive engineers, and pushing the methods down thesupply chain). However, the experience gained so farleaves Jaguar in a good position from which to addressthese issues, and roll out simulation and hardware-in-the-loop testing to a much wider set of automotive con-trol applications on its future vehicle programmes. Thishas the potential to contribute signi"cantly to the leap inengineering excellence that is required to meet the newtime-to-market and development cost reduction require-ments, such as those under FPDS, whilst keepingJaguar's products at the highest-quality levels.

Acknowledgements

The authors would like to thank David Maclay andChris Hayhurst of Cambridge Control Ltd, for theirtechnical assistance throughout, and Huy Ho from Jag-uar for his valuable contribution in providing correlationdata.

This work was supported by EPSRC as part ofthe University of Warwick Engineering Doctorateprogramme.

References

DePoyster, M., Hoyling, J., & Majeed, K. (1996). Rapid prototyping ofchassis control systems. SM03 2:10. Proceedings from the 1996 IEEEinternational symposium on computer-aided control system design (pp.141}145). NJ, USA.

Dorey, R., & Maclay, D. (1996). Rapid prototyping for the developmentof a powertrain control system. SM03 1:50. Proceedings from the1996 IEEE international symposium on computer-aided control systemdesign (pp. 135}140). NJ, USA.

Hanselmann, H. (1993). Hardware-in-the-loop simulation as a standardapproach for development, customization, and production test. SAEtechnical paper series, No. 930207. PA, USA: Warrendale.

Hanselmann, H. (1996). Hardware-in-the-loop simulation testing andits integration into a CACSD toolset. SM03 2:50. Proceedings fromthe 1996 IEEE international symposium on computer-aided controlsystem design (pp. 152}156). NJ, USA.

Harel, D. (1987). Statecharts: A visual formalism for complex systems.Science of Computer Programming, 8, 231}274.

Kendall, I.R., Jones, R.P., & Thomas, S.M. (1998). Simulation asa means of achieving `the impossiblea: An investigation into the useof simulation in the development of electronic control systems atJaguar Cars. Proceedings from the IEE simulation '98 conference(innovation through simulation) (pp. 99}106). IEE conference Publi-cation Number 457, London.

Potter, T. E. C., Cherry, A. S., & Jones, R. P. (1996). Modelling andsimulation of an automotive vehicle for integrated motion control.Proceedings of the international symposium on advanced vehicle con-trol (pp. 471}484). Germany: Aachen.

Ross, B., & Savage S. (1996). The XK8 body electronics control system.Proceedings from IEE special colloquium on the electrical system ofthe Jaguar XK8 (pp. 6/1}6/9). Digest No. 96/281. London.

Society of Automotive Engineers (1995). Class-B data communicationsnetwork interface. SAE Standard J1850. Warrendale, PA, USA.

Weeks, R., & Moskwa, J. (1995). Automotive engine modelling forreal-time control using MATLAB/SIMULINK. SAE technical pa-per series, No. 950417. PA, USA: Warrendale.


an investigation into the use of hardware-in-the-loop simulation testing for automotive electronic...

Documents