eme

M

eices

ed fe 29

Sensor-based driver assistance systems often have a safety-related role in modern automotive designs. In this paper we argue that thecurrent generation of Hardware in the Loop (HIL) simulators have limitations which restrict the extent to which testing of such sys-

trol units (ECUs) are connected to a variety of sensors and

Prospective designers have guidelines available to assistin the development process; for example the MISRA cod-

concluded that for certain system aspects, partial recom-

system architectures and their possible impact on safety,reliability and performance.

When developing such complex safety-critical systems, itis often inappropriate, unethical or even impossible to testthe system completely within its natural operational envi-ronment (Storey, 1996; Levenson, 1995). In such cases,

* Corresponding author. Tel.: +44 116 252 5052; fax: +44 116 252 2619.E-mail addresses: mjs61@le.ac.uk (M. Short), m.pont@le.ac.uk (M.J.

Pont).

Available online at www.sciencedirect.com

The Journal of Systems and Softwaactuators in order to realize high-level functionalityand services (Lean et al., 1999). To reduce cabling costsand improve exibility, these ECUs are connected to oneanother via one or more serial communication buses (Leanet al., 1999). With the advent of heavily sensor-based con-trol technologies and driver assistance systems, such asdrive-by-wire and automatic collision avoidance, these dis-tributed embedded systems (DESs) will have no mechanicalbackup and play a crucial role in safety (Iserman et al.,2002).

mendations can be made; for example the use of time-trig-gered (TT) communications (Albert, 2004) and TT taskscheduling (Bate, 1998) have both been found to make sys-tem behaviour more predictable. Even so, many factors areknown to inuence the reliability of a DES, including thechoice of hardware, programming language, communica-tion protocol, and software architecture (MISRA, 1994),and there still remains a huge amount of design scope.With an extensive array of options to choose from, thereis a pressing need to investigate the implications of dierenttems can be carried out, with the consequence that it is more dicult to make informed decisions regarding the impact of new technol-ogies and control methods on vehicle safety and performance prior to system deployment. In order to begin to address this problem, thispaper presents a novel, low-cost and exible HIL simulator. An overview of the simulator is provided, followed by detailed descriptionsof the models that are employed. The eectiveness of the simulator is then illustrated using a case study, in which we examine theperformance and safety integrity of eight dierent designs of a representative distributed embedded control system (a throttle- andbrake-by-wire system with adaptive cruise control capability). It is concluded that the proposed HIL simulator provides a highly eectiveand low-cost test environment for assessing and comparing new automotive control system implementations. 2007 Elsevier Inc. All rights reserved.

Keywords: Road vehicle electronics; Simulation; Distributed control; Road vehicle reliability

1. Introduction

In the modern passenger vehicle, up to 70 electronic con-

ing guidelines (MISRA, 2004), SAE J2056 (SAE,1993a,b) and general guidelines for good programmingpractice (Holzmann, 2006). Previous research has alsoAssessment of high-integritysystems using hardwar

Michael Short,

Embedded Systems Laboratory, University of L

Received 18 November 2006; received in revisAvailable onlin

Abstract0164-1212/$ - see front matter 2007 Elsevier Inc. All rights reserved.doi:10.1016/j.jss.2007.08.026bedded automotive controlin the loop simulation

ichael J. Pont *

ter, University Road, Leicester, LE1 7RH, UK

orm 7 August 2007; accepted 11 August 2007August 2007

www.elsevier.com/locate/jss

re 81 (2008) 11631183

hardware-in-the-loop (HIL) simulation of the systemand its environment can allow developers to make an initialassessment of performance without compromising safety.In addition, HIL simulation has been shown to bothincrease the quality and reduce the time-to-market (andhence development costs) for prototype vehicle systems(e.g. Ellims, 2000; Li et al., 2002; Kendall and Jones,1999; Hakiwara et al., 2002).

The principle of HIL simulation of an embedded system

1164 M. Short, M.J. Pont / The Journal of Systeis illustrated in Fig. 1. The embedded system outputs arefed directly to the simulator, where they are sampled andused as input variables. A dynamic simulation model, act-ing on these input variables, is evaluated (normally in real-time, but this is not always the case). The outputs from thesimulation, which are synthesized from the dynamic mod-el(s), are then fed back into the system under test as out-puts, thereby closing the control loop. Simulators of thisnature are not exclusive to the automotive domain andhave been used successfully in a variety of applications,including (for example) verication of new manufacturingmachine tool designs (Stoepler et al., 2005), commercialaircraft autopilot system design (Gomez, 2001) and numer-ous military applications (Cole and Jolly, 1996).

In this paper, we argue that many of the current gener-ation of automotive HIL simulator technologies are unableto test fully the safety and performance requirements ofnext-generation, safety-critical automotive driver assis-tance systems. We go on to suggest that there is a needfor low-cost, real-time, multi-vehicle simulator systemswhich can be used to explore the impact of sensor-basedcontrol systems, and which also feature the ability to injectfaults into the underlying hardware and software under testunder free-owing motorway trac conditions. We thendescribe the principle and implementation of such a testfacility.

The remainder of this paper is organized as follows. Sec-tion 2 provides an overview of the use of HIL simulatorand the evaluation of dependability and safety integrityin the automotive domain. Based on this discussion, Sec-tion 3 goes on to propose a set of requirements for futuresimulator environments which (it is argued) would helpto make such tools more useful. Section 4 provides an over-view of a simulator designed to meet these requirementswhile Section 5 details the development of models to repre-sent motorway vehicles. Section 6 goes on to developmicroscopic driver models for these road users, and pre-Fig. 1. HIL simulation principle.sents macroscopic simulation data. Section 7 then discussesan eective mathematical basis for the implementation offault injection and classication of resulting failure modes.Section 8 then introduces a generic, low-cost HIL simula-tor framework that has been used for the implementationof the simulation models. In Section 9, we summarize anextended case study, which was performed using the facilityto investigate the performance and safety/reliability ofeight dierent versions of a test system, a distributed throt-tle- and brake-by-wire system with adaptive cruise control.Section 10 presents our conclusions and suggests possibleareas of further research.

2. Previous work in this area

In the Introduction, it was argued that many of the cur-rent generation of HIL simulators may not allow a fullassessment of the next-generation of vehicle control sys-tems. A summary of some of the features of current simu-lators, along with a discussion of the inherent problemsencountered when assessing safety properties of automo-tive systems, is provided in this section.

2.1. Automotive ECU design

In the automotive sector, HIL testing techniques havebeen successfully employed for a number of years: Ellims(2000) provides a good summary and general overview ofsome typical techniques that have been employed. Froma starting point in the early 1980s, when low-cost process-ing power allowed HIL systems to become feasible, manyspecic companies developed their own closed, proprietarysystems tailored to the needs of individual manufacturersand products. With the subsequent emergence of generic,model-based dynamic simulation tools for desktop PCs,such as Matlab and Simulink, these have now becomethe preferred tools for many developers of automotiveHIL simulators (Mathworks, 2007).

The types of embedded control systems tested usingthese means typically include ECUs used to run internalcombustion engines and to provide anti-lock braking facil-ities. They typically consist of small-scale simulations of asingle vehicle (or part thereof) and its engine. For example,Li et al. (2002) describe the use of a HIL system for therapid development and validation of a vehicle ABS systemusing Simulink and the Real-Time-Workshop tool. Ken-dall and Jones (1999) document an almost identical meth-odology that was used to develop the main body controlECU functionality for a Jaguar vehicle. Hakiwara et al.(2002) demonstrate the use of Matlab, MATRIXx anddSpace in the accelerated design of a vehicle automatictransmission ECU.

As can be observed from these studies, and many othersin the literature, these environments and tools allow formuch exibility and have been employed for a host of vehi-

ms and Software 81 (2008) 11631183cle systems. However, such simulations are limited to mod-els of a single vehicle, driver, and tire/road interface, and

ystedo not include free driving conditions in realistic tracows. As such, the impact of sensor-based driver assistancesystems cannot be fully explored, as the trac pattern onroadways is emergent from not only the control systemsunder investigation but also the behaviour of surroundingdrivers (Bullock et al., 2004).

For example, the addition of a lead vehicle into a simu-lation may be used to verify the basic performance of anACC system. However, an extended 1999 study of a com-mercial ACC system revealed a potentially dangerous con-dition that caused distress to the majority of drivers whoexperienced it (Fancher et al., 1998). It must be noted thatthis was not due to a software defect, as the controller wasperforming according to its specications. Since the tracsituation that caused the condition could only arise underfree-owing multi-lane driving conditions, this would neveroccur in the simplied simulation suggested above; it fol-lows that no amount of testing would uncover thissituation.

2.2. Simulation of trac ow

Although most existing HIL testing facilities do notinclude such features, the simulation and analysis ofmotorway and city trac ows is an in-depth and widelycovered subject, with many diering approaches describedin the literature (e.g. Yang, 1997; Wu et al., 2000; Gipps,1986).

A survey all such methods is beyond the scope of thispaper. However, it can be observed that the vast majorityof the software tools that do exist to model these phenom-enon, such as the Paramics package (Paramics, 2007), areo-line (and hence non-real-time) graphical environments,employed in most cases by engineers primarily concernedwith trac signaling and transport planning.

More recently, there has been much research interest inadaptive real-time trac signaling. However it has beenrecognized within the community that many of the popularsimulation packages (such as Paramics) do not have thecapacity to directly integrate these newer signaling algo-rithms into their simulation environments; there is also aneed to investigate the eects of the actual implementationhardware, which may be distributed over physical distancesof several kilometers (Bullock et al., 2004; Courage andLee, 2005). To overcome these problems, researchers havesuggested (and implemented) real-time microscopic tracow models in dedicated HIL facilities (Bullock et al.,2004; Courage and Lee, 2005).

Such solutions have many attractive properties from theperspective of investigating in-vehicle sensor-based controltechnologies; however two main limitations still remain.The rst is that these systems, by denition, concentrateon xed signaling installations (such as ramp meteringfor motorway intersections) and the time duration that asingle vehicle is actually present within this xed area is

M. Short, M.J. Pont / The Journal of Svery short; although trac ow is simulated, it does notconcentrate on a single vehicle traveling under free-owingmotorway conditions. The second problem is the time res-olution of the simulations; the simulations that have beenreported in the literature have update intervals rangingfrom hundreds of milliseconds to tens of seconds. Therequired timing resolution for investigating the type of con-trol systems that this paper is concerned with is in the mil-lisecond area.

There are, however, a limited number of large-scale real-time driving simulators with HIL testing capabilities. Forexample, the AutoSim driving environment can be modi-ed to allow external hardware to interact with a full-scalesimulation of motorway or city driving (AutoSim, 2007).Although primarily intended for human factor research(it has a vehicle chassis mounted on a Stewart platform)it can-at least in principle-be used for HIL, although howthe required on-vehicle sensors would be integrated intothe system is not clear.

The Vehicle Hardware-In-the-Loop (VEHIL) system isa natural extension of such a large-scale simulator speci-cally designed for testing the type of driver assistance sys-tems we are concerned with in this paper (Verburg et al.,2002). Although only partially complete, when nished itslarge implementation scale requires a test facility the sizeof a warehouse; a fully instrumented test vehicle is placedon roller bench, and other trac participants (vehiclebodies mounted on movable bases) are directly controlledby a central computing facility implementing a trac sim-ulation. The host vehicle is equipped with real sensors, andthey thus generate realistic signals for the controlhardware.

Despite many advantages, such systems (by their verynature) are extremely costly, and their sheer physical sizeand complexity mean that dedicated personnel are neededto maintain and operate them. Such systems are beyondthe reach of most researchers and engineers.

2.3. Assessment of system performance

From the perspective of functional performance assess-ment of distributed/embedded systems, a variety of suc-cessful techniques have been suggested in the literature.With application to control systems, these include (butare not limited to) quality measures based upon outputerror (e.g. Franklin et al., 1994; Torngren, 1998) and per-formance monitoring (e.g. Li et al., 2003), and more gener-ally quantications of jitter, delays and latency plusmeasures of processor and memory utilisation in the sys-tem have all been suggested as useful (and sometimes nec-essary) benchmarks to evaluate (Bate, 1998; Pont, 2001;Storey, 1996; Torngren, 1998). All of these techniques areparticularly well suited to HIL simulation, as they can bedirectly integrated into the hardware and softwareinfrastructure.

Performing rigorous assessments of safety and reliabilityproperties of complex, reactive automotive control sys-

ms and Software 81 (2008) 11631183 1165tems, however, is a wide and ongoing area of research.Many automotive systems are safety-critical in nature,

ysteand hence special measures must be taken at all stages ofthe design process to ensure that the required Safety Integ-rity Level (SIL) has been achieved. SILs are a safety mea-surement standard developed by the IEC (Standard 61508):a discussion of how these measurement standards apply tothe automotive domain may be found in (MISRA, 2001).The SIL of a system depends on the consequences of sys-tem failures, which can be determined using risk assess-ment; a required dangerous failure rate kd is thenassigned for a system based on this risk. Demonstratingthat the dangerous failure rate for a system is at a speciclevel requires many factors to be taken into consideration;a major element in this process is the determination of reli-ability measures for each subsystem and component.

The traditional method of validating reliability isthrough life testing: however for software-based systemsdesigned to have a failure rate less than 105, such as thoseconsidered in this paper, this form of testing is impractical(on any reasonable timescale) and alternate means must beconsidered (Butler and Finelli, 1993).

Aside from the simplest of automotive systems, mostsuch designs will employ some form of redundancy for tol-erance to faults and failures in subsystems to achieve therequired levels of safety integrity (Storey, 1996). Thisredundancy can take many forms; static and dynamicredundancy of electronic components and processing ele-ments, communication systems and sensor/actuator sub-systems in conjunction with software-based redundancymanagement algorithms (Iserman et al., 2002; Hammett,2002). In such cases, fault injection is the preferred meansfor extracting dependability information (e.g. see Arlatet al., 1993). Fault injection enables the estimation of faultcoverage parameters for analytical system models; howevergreat care must be taken in selecting appropriate testsequences and determining representative rates of faultoccurrence for such experiments.

One interesting area of research has involved the rareevents technique (RET). The RET originated in the eldof Operations Research as a methodology for speeding upsimulations in which certain events of interest occur withextremely low probability: Heidelberger (1995) provides auseful survey of this technique. The primary aim of theRET is to determine the eects of rare events using simula-tion models such asMarkov chains. From the perspective ofreal-time HIL simulation, the RET seems particularly sui-ted for use in automatically generating representative testsequences (in a relatively short space of time) for the systemunder investigation. This is because the events of interest(such as sensor failures) happen very rarely.

Despite suggestions (e.g. Hecht and Hecht, 2000; Tanget al., 1997) that the RET is particularly suited for integra-tion into the high-integrity software reliability evaluationprocess, to the authors knowledge this possibility has yetto be explored in full. In addition, the use of the techniqueto generate the test sequences that the evaluation is to

1166 M. Short, M.J. Pont / The Journal of Sbased on has yet to be considered in the literature, despiteits seeming suitability.3. Proposed system requirements

Section 2 highlighted some of the limitations of existingHIL simulation frameworks. As an alternative to existingdesigns, we propose the following list of requirements fora next-generation comprehensive, low-cost and open-source HIL simulator for automotive control systems:

The platform must integrate a high-delity simulation ofa vehicle under test along with its interactions with otherroad users in free-owing trac conditions, having avariable and temporal resolution suitable for the appli-cation under investigation.

It must be suitable for both the rapid prototyping andsafety testing of driver assistance systems implementedusing realistic ECU hardware. This will allow the boththe operational and safety impacts of new technologiesand control methods to be investigated simultaneously.

The software architecture must be exible enough toallow (for example) the use of vehicle code generatedfrom existing tools (such as Simulink), and the integra-tion of models and code developed from other areas oftransportation research. This will allow the simulationto be upgraded as more realistic models are developedand help ensure that existing models are not renderedunusable.

It must feature an ability to repeat tests under tightlycontrolled conditions using a form of scripting. This willallow complicated testing programs to be managed anddocumented accordingly.

For dependability evaluation purposes, it must allow thecontrolled injection of a range of representative faultsinto the underlying hardware and software, based on afailure model of the system under test; this proceduremust be as automated as possible, and designed to max-imize the statistical coverage of the possible test cases.

It must be based on a exible and low-cost hardwareplatform that can be assembled and maintained by a sin-gle person. This will enable small, independent groups ofresearchers to maintain such a facility.

In the remainder of this paper, we describe the design,implementation and assessment of a prototype HIL simu-lator which was designed to meet these requirements.

4. Overview of the trac simulation

In this section we provide an overview of the real-timetrac simulation which was employed in our prototypeHIL system.

4.1. Simulation scope

The simulation described in this paper provides a real-time microscopic representation of road users traveling

ms and Software 81 (2008) 11631183down an innitely long three-lane motorway (plus hardshoulder) in the UK. Road users are represented over a

ay

ystems and Software 81 (2008) 11631183 11672 KM (1.24 mile) section of road, at the centre of which liesthe host vehicle (which is controlled by the embedded sys-tem under test). The co-ordinates of the simulated road sec-tion are implemented as a moving frame of reference that isattached (longitudinally) to the host vehicle (Fig. 2). A con-sequence of this is that the relative velocity between thehost and each other vehicle dictates their position in thesimulation, as time advances. The hard shoulder lies tothe leftmost (slowest) lane in the gure and is labeled Lane0 it is only used for emergency purposes.

The simulation has an initialization procedure, whereeach simulated vehicle is assigned a desired speed and fol-lowing headway, and given an initial position in the simu-lation plane. As the simulation evolves, faster vehicles exitthe frame of reference to the host vehicles front, whileslower vehicles exit to the rear. When this occurs, new vehi-cles will be generated and assigned desired speeds andheadways, entering either the front or rear of the simula-tion depending on the current velocity of the host.

The version of the simulation described in this paper isconcerned with control of the host vehicle longitudinalvelocity only: this is reected in the granularity of the hostvehicle dynamic model. The additional road users consistof heavy goods vehicles (HGVs) and passenger vehicles,while the environmental variables included in the simula-tion consist of the road gradient, trac density, weatherconditions and prevailing wind/turbulence level.

4.2. Statistical data

In the system described in this paper, the simulation rep-resents is a section of the M1 motorway, to the south ofLeicester (UK). The statistical data that is to be used to

Fig. 2. The motorw

M. Short, M.J. Pont / The Journal of Sobtain parameter information for the simulation was takenfrom several sources; a 1994 video study of 500 m of thissection of motorway (McDonald et al., 1994) and Govern-mental statistics reports (DFT, 2003, 2004). From thesesources, it was found that the overall distribution of desiredspeeds for passenger vehicles possesses a slightly negativelyskewed distribution with a mean centered on the speedlimit of 112.7 KPH (70 MPH). For HGVs, many of whichare tted with speed restrictors, it has slightly morepronounced distribution centered at approximately85.3 KPH (53 MPH). In both cases, since the amount ofskew is relatively small, for simplicity the distribution ofdrivers desired speeds was taken to be normal. The aver-age percentage of HGVs was taken to be approximately20%.

The average trac ow for the M1 in this area wasfound to be 4167 veh/h, with an absolute maximum owof 6750 recorded. The 1/3 and 2/3 lane occupancy cross-over points,1 with 1 being the slowest lane and three thefastest, occurred at ows of approximately 2700 and3350 veh/h, respectively. Sucient data was not availableregarding the 1/2 crossover point, however it could be esti-mated to occur at a point between 1500 and 2000 veh/h byextrapolating the existing data. The lane occupancy wasapprox 30% at the 1/3 crossover point, and 37% at the 2/3 point. The lane change rate was found to vary quitewildly, even for identical trac ows occurring at dierenttimes, with an approximate mean located around1100 events/km/h for ows greater than 2000 veh/h.

5. Modelling the vehicle dynamics

This section describes the dynamic models that were cre-ated to represent the operation of both the host vehicle andthe additional road users.

5.1. Host vehicle

The version of the simulation described in this paperwas concerned with longitudinal vehicle dynamics only.For this reason, a two-wheel traction model was chosento represent the host vehicle (Gillespie, 1992). A schematicof this model is shown in Fig. 3.

The resulting dynamic equations that were created toimplement this model were non-linear and of high order.A block diagram outlining the main elements of the vehicle

co-ordinate system.model, and the system variable dependencies between themis shown in Fig. 4. A summary of the development of theequations of motion, powertrain model and selection ofsuitable parameters may be found in Short et al. (2004a).The so-called Pacejka magic model was used to capturethe dynamics of the tire/road interface (Bakker et al.,1989). In the simulation, the dynamics of the host vehiclewere updated every 1 ms.

1 A lane occupancy crossover point is the value of trac ow at whichthe observed occupancy in two trac lanes becomes identical. Hence, the2/3 lane crossover point is the observed trac ow, in vehicles/hour, atwhich the middle lane occupancy equals the fast lane occupancy.

5.2. Additional road users

Additional road users are represented by a simplieddynamic model, which is given by Eq. (1), where x2 is thevehicle velocity and x1 the vehicle position

_x1 vh x2_x2 minaa; amax

1

The host vehicle velocity is vh, and the vehicle driver pro-vides the acceleration signal aa. The saturation level amaxtakes into account the vehicle speed, gradient and roadcondition to provide realism, as described by Yang

nal and lateral vehicle control. Although soft computingtechniques (such as fuzzy logic; Wu et al., 2000) have beenfound to be useful for modelling driver behaviour, we haveopted to use a simpler approach in the present simulation,in order to reduce the computational load.

6.1. Longitudinal

In this simulation two dierent types of longitudinalmotion are to be modeled:

Free Driving the driver endeavors to achieve andmaintain the desired speed.

Car Following the driver attempts to maintain a safedistance to a leading vehicle in the same lane.

In both cases, the driver behaviour was implemented asa feedback control system acting on the simulation kinet-ics. The free driving model was implemented as a propor-tional controller producing an acceleration signal afd, andthe car following model as a proportional-velocity control-ler producing an acceleration acf. The actual applied accel-eration signal aa was taken to be the minimum of the two,

6.2. Lateral

Fig. 3. The two-wheel traction model.

1168 M. Short, M.J. Pont / The Journal of Systems and Software 81 (2008) 11631183(1997). The dynamics of additional road users were up-dated every 10 ms.

6. Modelling the driver

In order to provide the acceleration signals for the addi-tional road users, and to decide when to change lanes, weimplemented microscopic driver models for both longitudi-Fig. 4. Host vehicle mo

Fig. 5. Longitudinal accLane changing is a notoriously dicult and complexbehavioural process to model. It is best considered in terms

del block diagram.to provide smooth switching between controllers. A blockdiagram of the controller is shown in Fig. 5. The control-lers are updated every 10 ms in the simulation.eleration controller.

of a number of perception thresholds, which consider therisk involved in accepting a gap in neighboring lanes, com-pared to a benet factor of some kind when performing themaneuver (McDonald et al., 1994). This simulation is con-cerned with discretionary lane changes only, since themotorway is considered innitely long. Three rules wereconsidered:

1. Drivers side change (overtaking) the driver perceives acertain speed benet in moving to a faster lane.

2. Passenger side change (yield) the driver perceives a fas-ter car approaching from the rear.

3. Passenger side change (KLEWO) the driver movesover to the left after overtaking.

In this equation, ys is the initial y co-ordinate (at timet = t0), and yd is the nal y co-ordinate (at timet = t0 + t1). The trajectory accommodates a changingvelocity v, and the change time t1 was made inversely pro-portional to the move urgency, centered on a mean maneu-ver time of 6.2 s (Olsen et al., 2002). The lane changemodels are updated in the simulation every 10 ms.

6.3. Parameter selection

The longitudinal and lateral driver models both possesscalibration parameters that determine how aggressivelythey will react to the road conditions around them. In

M. Short, M.J. Pont / The Journal of Systems and Software 81 (2008) 11631183 1169KLEWO (Keep Left Except When Overtaking) refers tothe driving convention in the UK, but it is clear that this isnot always adhered to (McDonald et al., 1994). The lanechange model developed for this simulation consists of adriver side change model that implements Rule 1, and apassenger side change model that implements Rule 2 andRule 3. The models consist of a simple gap acceptanceprinciple, where the gap is dened as the time headwayto nearest vehicle in the destination lane both to the frontand rear of the considered vehicle. A maneuver is per-formed when both the minimum gap distances (as givenby Gipps, 1986) are cleared, and the stimulus is sucientlystrong for the available gaps. A non-linear urgency modelwas created to relate the threshold for maneuver initiationto the current road conditions. A block diagram of the lanechange models is shown in Fig. 6. The non-linearity wasimplemented as a scaled exponential function, with a totalof seven parameters dening the lane change model. A fulldiscussion of the nature of the models may be found inShort et al. (2004b).

The actual lane change itself is implemented as a sinusoi-dal trajectory, described by Eq. (2):

yt ys yd2 sin p 2p t t0

t1

yd

22Fig. 6. Lane change models.the case of the longitudinal model, a study by Fang et al.(2001) have shown that a proportional gain Kp between0.02 and 0.24 (with a half-normal distribution) generatesrealistic behaviours. Once a value of Kp has been generatedfor a particular driver, the velocity gain Kv may beobtained from Eq. (3)

Kv 0:1839 2:5719Kp 5:5182K2p 3

A simple optimization procedure was used to modify theparameters of the lane change model to produce macro-scopic ow/lane occupancy behaviour close to that ob-served in practice (McDonald et al., 1994). The hostvehicle was replaced during this procedure by the simpliedvehicle model given in Section 5.3. A number of simula-tions were automatically run in a super loop with an in-creased time-step of 1 s, for a duration of 60 simulationminutes. An additional 10 min of initial data were dis-carded to allow any transients to subside. Each test wasduplicated ve times with dierent initial seeds in the ran-dom number generator, and the averaged results taken.The overall trac ow and lane occupancy were calculatedat each time instant, and averaged over the test duration.

The algorithm that was used simply made small changesto the value of each parameter, from an initial guessti-mate, in order to reduce the error between the simulationresult and the empirical data, at the lane crossover points.The target error was set at 5% of lane occupancy. TheFig. 7. Simulation trac ow vs. lane occupancy.

resulting parameter set that was selected for use in the sim-ulation produced an overall trac ow/lane occupancyrelationship as shown in Fig. 7. The corresponding lanechange rate was found have a mean located at

k mT naT

7

However, we assume that the system should not fail forroutine inputs: m should, therefore, be zero (if this is notthe case then further, standard testing should be performedto remove these high-intensity bugs). Alternatively, as isthe approach suggested in this paper, statistical informa-tion regarding these measured failures may also be used

1170 M. Short, M.J. Pont / The Journal of Syste1250 events/km/h for ows greater than 2000 veh/h.Finally, we note that large changes in the observed

ow/lane occupancy can be observed by altering theparameters in these driver models; the models may, there-fore, be calibrated to a wide variety of road types, andempirically observed motorway ow regimes.

7. Assessment of safety integrity

In this section we describe a means, based on fault injec-tion and the rare events techniques (RETs: reviewed brieyin Section 2.3), for performing assessments of safety integ-rity. We begin by describing the mathematical basis foraccelerating the occurrence of rare events in the simulation,and how this capability can be added into the simulator.

7.1. Accelerated fault injection

The RET, as applied in the context of high-integritysoftware evaluation, starts from a single basic assumption:

Well designed software does not fail in routine operat-ing conditions

This assumption is validated by numerous data fromsources such as NASA (Lutz and Mikulski, 2003; Tanget al., 1997). In addition, when software has been designedusing the rigorous techniques that are mandated for high-integrity systems (e.g. see MISRA, 2004; Holzmann,2006), and put through an initial test/debug phase, it canbe assumed that all high-intensity defects have either beendesigned out of the system or have been removed duringinitial testing.2 It follows that all subsequent failures arecaused by non-routine conditions such as abnormal/unex-pected input sequences, erroneous computer states andhardware failures (Hecht and Hecht, 2000; Lutz andMikulski, 2003; Tang et al., 1997).

The rare events technique allows a qualitative assess-ment of the system under test by exploiting the discontinu-ity between routine systems events, and abnormal orrare system events. Although determining the operationalprole for sets of system inputs is (in general) extremely dif-cult, since most rare events (such as abnormal inputs) aregenerally caused by well-understood physical phenomenon,there is normally a single point which can be selected to dis-tinguish between normal and abnormal operation(Hecht and Hecht, 2000; Lutz and Mikulski, 2003). This

2 Indeed, where formal techniques have been employed in the softwaredesign process, it may be mathematically provable that all such defectshave been removed. However, even in such cases there is a need to validatethat the design specication itself is correct, especially when the speci-

cation contains functional techniques for the management and toleranceof unexpected system conditions such as hardware failures.is highlighted in Fig. 8, showing the operational prole ofa typical system and highlighting the point Prare where nor-mal operation ends and abnormal operation begins.

Also indicated in Fig. 8 is an upper limit Pupp, which isan estimated upper bound for all the rare/critical opera-tions of the system; that is the probability of a critical orrare event Pc is limited as follows:

P rare < Pc < P upp 4In particular, to make the assessment of failure rate, theentire operational prole of the system is placed into oneof two sets [1] the regular set containing operationsor1,or2, . . . ,orn or [2] the critical set containing opera-tions oc1,oc2, . . . ,ocn. The associated probabilities ofoccurrence for these operations are then pr1,pr2, . . . ,prnand pc1,pc2, . . . ,pcn, satisfying the conditions shown inEq. (5)

P r Xni1

pri; P c Xni1

pci; P r P c 1 5

where Pr Pc in order to maintain consistency with theassumptions above (and shown in Fig. 8).

In order to exploit the limited test time available for thereliability assessment, the probabilities of occurrence of theoperations in the critical test set are adjusted during theperiod of testing T, giving pc01; pc

02; . . . ; pc

0n, by a likelihood

ratio a (see Eq. (6))

pc0i pci a 6where the likelihood ratio a is chosen as some suitable va-lue for a tractable test, e.g. 1/Prare.

Suppose that during the testing time T, both routineoperations and critical operations are randomly selected(with adjusted critical operation probability). If m failuresare observed due to routine operations, and n failures areobserved due to critical operations, the failure rate k maythen be calculated as shown in Eq. (7)

Fig. 8. Normal and abnormal operational proles.

ms and Software 81 (2008) 11631183to estimate the fault coverage probability for each rareevent that has been considered; this may be then further

utilised in reliability models to reason about system failurerates. Assuming a sensible choice is made in the selection ofa, a suitable statistical model may be calibrated to selecttest patterns for the HIL system to simulate abnormal envi-ronment conditions. Assuming that the fault activationtime for the system is much less than the total available testtime T, and observing that the average mission time for anautomobile is comparatively short (and that a safe statecan be entered upon detection and tolerance of a subsystem

8. Implementing the simulator

In this section we describe the hardware and softwareframework that we developed in order to implement thesimulation models described in the previous sections (andto meet the requirements proposed in Section 3).

8.1. General conguration

M. Short, M.J. Pont / The Journal of Systems and Software 81 (2008) 11631183 1171failure in a very rapid time), then we would suggest thatcondence may be gained in the assessment of failure rateby testing for a duration of approximately 10 times theMTTF of the target failure rate, adjusted by the inverseof the likelihood ratio. For example, if the target failurerate of a system is 107 failures/h, then with a = 106 thesystem must be tested for a minimum of 100 h under statis-tical fault injection.

However, in order for this to be implemented, accuratetesting of both routine and critical (rare) operations mustbe achieved: this implies that a form of physical fault injec-tion must be used. Such a mechanism for use in thesesituations is described in detail elsewhere (Short and Pont,2007b) and will be briey outlined in Section 8. Thistechnique also requires that system failures can be accu-rately classied and recorded during long periods of auto-mated testing; a solution to this problem is outlined inSection 7.2.

7.2. Automated performance monitoring

The technique for automated monitoring of system per-formance and failure mode classication that is to beemployed in the facility described in the present paper isbased around the concept of model-based control systemmonitoring. A real-time performance monitor is intro-duced into the simulator environment that compares thebehaviour of the real, hardware/software-based systemwith the desired system behaviour (see Fig. 9). The perfor-mance monitor that is to be employed is an adapted versionof the design presented by Li et al. (2003). The monitor isused to detect persistent deviations from the specicationthat are indicative of system failures (e.g. sluggish/oscilla-tory performance, out of range or stuck at errors), andalso catastrophic failures such as rear-end collisions, orthe vehicle becoming stranded or otherwise out of controlon the motorway.Fig. 9. Real-time perforThe system is based around three standard desktop PCs,without the need for expensive or proprietary interfaceequipment. Fig. 10 shows the overall simulator architecture.

A primary PC, running the DOS operating system (orequivalent), is used as a host for the main real-time ele-ments of the software: this is shown as the vehicle/motor-way simulation PC in the Figure. Software libraries havebeen created to perform real-time task execution via ascheduler and provide interfaces to both the parallel andserial ports for digital, analogue and serial I/O. Librarieswere also created to implement the performance monitoras discussed in Section 7.2. An additional library was cre-ated to log simulation variables, system performance andfailure modes and to transmit these to a second PC, for dis-play and user interface purposes.

The second (optional) PC runs the Windows operatingsystem, and is labeled the display/analysis PC in the Figure.If used, this employs a (custom) software library to decodethe simulation information transmitted from the primaryPC. A further library was also created for this second PC(using OpenGL): this allows 3D visualization of the simu-lation information. This interface can be used to shows thesimulation evolving in real-time from the perspective of thedriver of the host vehicle. A sample screenshot of the userinterface is shown in Fig. 11. Software was also created toupload and analyze data les generated by the main PC. Inboth cases, the libraries and analysis tools consist of codeand components for the Borland C++ Builder develop-ment IDE (Hollingwood et al., 2001).

The third (optional) PC again runs the DOS operatingsystem, and is labeled as the fault injection PC in the Fig-ure. Software libraries again are used to perform real-timetask execution via a scheduler and provide interfaces toboth the parallel and serial ports for digital, analogueand serial I/O. Libraries were also created to implementand manage the rare events technique as discussed in Sec-tion 7.1.mance monitoring.

ysteFig. 10. Simulator framework. In the Figure the hard real-time applica-tions run on DOS-based PCs while the soft real-time applications run on aWindows PC.

1172 M. Short, M.J. Pont / The Journal of S8.2. Timing considerations

To support the execution of tasks in the primary andtertiary simulation PCs, we created a DOS-based time-trig-gered, co-operative scheduler, driven by the system timer(as described in Pont et al., 2003). This type of schedulerwas implemented because it is known to be highly stable,is well suited to periodic execution of dynamic models,and possesses low memory and CPU overheads when com-pared to other forms of scheduler (Pont, 2001).

Although the application running on the secondary PCis designed to be time-driven via the underlying data trans-fer protocol, a Windows-based scheduler was also createdto allow other tasks to be executed in a timely fashion. Thetimer for this scheduler was provided by a high-priorityDeferred Procedure Call (DPC) from a multimedia timer(Microsoft, 1998).

8.3. Interface considerations

To keep costs to a minimum, the input/output interfaceis implemented entirely through the use of standard PCserial and parallel ports. Digital TTL inputs and outputscan be used with ease (a method for creating virtual portsis detailed in Pont et al., 2003).

Fig. 11. Simulator user interface.Analogue signals can be interfaced to the simulation viasimple interfaces using low-cost, low-power ADC/DACchips connected to the parallel port (Analogue Devices,1998). Drivers have been created to allow both readingand writing of the digital and analogue signals. Please notethat, for an eective simulator, it is usually argued thatanalogue signals should be sampled and generated with agreater resolution than the system under test, and thatthe update interval of the dynamic model(s) should be inthe region of 510 times smaller (Gomez, 2001).

For serial digital I/O, drivers have been created for syn-chronous and asynchronous RS232 communication. Thehardware and software fault-injection mechanisms can beimplemented via these interfaces.

8.4. Simulator control

In order to allow the simulator to be used for a widevariety of dierent scenarios, a simple script le interfaceallows control of system variables. In this case, the lesinclude such variables as trac density, road gradient,weather conditions (for creating specic scenarios), anoption that allows variables to be set randomly by the sim-ulator, and the total test duration. These script les, whichhave a simple text format, contain both initialization andrun-time information. The script les also contain informa-tion pertinent to the rare events technique, such as thestructure of the system under test (number of nodes, num-ber of communication buses, number and type of sensors,etc.) and the representative failure rates for each individualcomponent. They also contain information regarding anyadditional rare events to be considered (such as transientinterferences), their natural rates of occurrence, and thelikelihood ratio to be employed during the test run.

8.5. The system conguration employed in this paper

The HIL simulator described in this paper was imple-mented using three standard desktop PCs. The primaryand tertiary real-time PCs had a clock speed of 400 MHz,and the secondary graphical interface PC has a clock speedof 700 MHz. The primary PC scheduler was conguredwith a tick interval of 1 ms, while the tertiary PC was con-gured with a tick interval of 5 ms. The secondary PCscheduler was not required in this case, as the periodictransmission of simulation data was used as the time refer-ence to update the GUI.

In the implementation described in this paper, a total offour parallel ports were used for I/O purposes on the pri-mary PC. Ten analogue output signals were generated fromthe primary PC. No analogue inputs were required. A sin-gle RS232 channel (in addition to the high-speed links tothe secondary/tertiary PCs) was required. In total, 45 dig-ital inputs and 11 digital outputs were used.

These basic I/O channels were extended into the simula-

ms and Software 81 (2008) 11631183tion by the use of virtual sensor and actuator interfaces,which represent individual sensor/actuator dynamics, mea-

mentary evidence demonstrating its suitability may befound elsewhere (Short and Pont, 2007c).

9. Case study

In this section, to illustrate the use of the HIL simulatordescribed in this paper, we present the results from a repre-sentative case study.

safe distance to any leading vehicles (see Fig. 12). The sys-

ystems and Software 81 (2008) 11631183 1173surement accuracy and noise models. In this case parame-ters for time constants and the accuracy of each virtual sen-sor/actuator in the simulation were taken frommanufacturers data sheets and survey data (Turner andAustin, 2000). The sensor and actuator models were codedinto tasks which were updated every 1 ms in the simulation.

On the tertiary PC, a total of two parallel ports wereused for I/O related to fault injection. No analogue inputsor outputs were required. A total of 30 digital outputs weremade available for connection to relays, allowing hardwarefaults to be injected (e.g. to simulate broken signals or lossof power). Twelve RS232 channels were made available forthe injection of transient software faults into the microcon-trollers under test. A non-intrusive and high performancefault injection protocol was created to implement thesefaults. The protocol itself operates via the PC serial portand on-chip UART of the microcontroller under test,and is based on the well-understood bit ip or upsetmodel. Such an approach has been shown to be representa-tive of a wide range of transient faults in embedded systems(Arlat et al., 1990). Briey, the protocol operates as fol-lows. Three control bytes are sent by the PC, invoking ahigh-priority interrupt in the microcontroller. Fault injec-tion is achieved by the use of pointer indirection to achievethe bit ips; further information is provided elsewhere(Short and Pont, 2007b).

Implementation of the rare events technique wasachieved as follows. Initially, a statistical fault model wascalibrated using information provided in the script les:component failure rates were adjusted using the speciedlikelihood ratio. This statistical fault model was then eval-uated very 5 ms, and a pseudo-random number generatorwas employed to evaluate the health of each componentat every iteration of the model (a form of Monte Carlostyle simulation). When the model indicated that a partic-ular component failure or rare event had occurred (eithertransient, permanent or intermittent), this was physicallytransferred to the equipment under test using faultinjection.

We also measured the total PC CPU utilisation on thechosen hardware. This was found to be less than 90% onthe primary PC, and less than 30% on the tertiary, bothwith bounded worst-case task execution time, even whenin excess of 120 vehicles and drivers were being simulated.On the secondary PC, the CPU utilisation was measured at60% when implementing the GUI with the maximum num-ber of vehicles being displayed. We, therefore, suggest thatthe model code, rare event code and display code we havedeveloped is both portable and suitable for simulating hightrac ow regimes in real-time, on low-cost non-special-ized computer hardware.

Given the fact that we wished to employ the test facilityto make judgements regarding the safety integrity of thesystems under test, it was required to demonstrate thatthe facility itself exhibits a desired level of integrity. In light

M. Short, M.J. Pont / The Journal of Sof this, a variety of techniques were thus employed to dem-onstrate that the facility was indeed t for purpose. Docu-tem also sends status information to the driver.The system under consideration in this study is a Type

2b ACC system: such a system employs active braking.Vehicle acceleration is limited to 2.0 m/s2, deceleration to3.0 m/s2 in order to comply with ISO standards (ISO,2003). Further details of the nature of the controller itselfmay be found in (Short et al., 2004c).

When the cruise control system is disengaged, the throt-tle and brakes are activated via electronic signals from sen-sors attached to both the brake and throttle pedals. Giventhe level of risk associated with each element of the system,9.1. Overview of the case study

The case study presented in this section involves the useof an Adaptive Cruise Control (ACC) system. Specically,the study explores the behavioural eects and safety integ-rity impacts of employing dierent numbers of processornodes and communication system congurations in eightdierent implementations of the ACC system. We beginthe description of the case study by summarising the prin-ciples of ACC.

9.2. ACC description

ACC is a relatively new technological development inthe automotive eld, and is said to reduce driver fatigueand the rate of auto accidents, whilst increasing fuel e-ciency (Stanton et al., 1997). The main system functionof ACC is to control the speed of the host vehicle usinginformation about the distance between the subject vehicleand any forward vehicles (using Doppler radar), themotion of the subject vehicle itself and commands fromthe driver. Based upon this information, the controllersends commands to the vehicle throttle and brakes to eitherregulate the vehicle speed to a given set value, or maintain aFig. 12. ACC concept.

we classied the required Safety Integrity Level (SIL) forthe overall system at SIL 3, with a minimum failure rateof 107 dangerous failures/hour. The rationale behind thisdecision was taken directly from MISRA guidelines (MIS-RA, 2001).

9.3. Eight dierent system implementations

resulting in complete loss of throttle and brake actuatingability. In all other systems, however, a single brake proces-sor loss will have a reduced impact on braking capacity andno impact on throttle actuation ability. In addition, thepresence of the backup Master in the ten node systemensures that in case the main Master fails (silently), the sys-tem will not lose its global clock and hence time-triggeredcommunication capability (this is explained further in Sec-tion 9.5). The backup Master employs dynamic redun-dancy with fault detection, i.e. it self-activates when theloss of the main Master is detected.

In addition to this, in order to investigate the impact ofcommunication system redundancy on the performanceand safety integrity of each design, we also implementedeach of these four microcontroller congurations in a dualCAN network conguration. The methodology employedto achieve this was previously described by the authors in

1174 M. Short, M.J. Pont / The Journal of SysteIn many application areas, system designers have someexibility in decisions about the number and location ofprocessor nodes, and in the allocation of software tasksto particular nodes.3 As dierent network topologies areconsidered, it is important that the designer should under-stand the implications that a particular choice may have onthe systems performance and safety. In the study describedin this paper, we wished to explore the ways in which theHIL simulator (described in previous sections) could beused to support the process of comparing dierent systemdesigns.

The particular focus of the study was to explore the linksbetween the chosen microcontroller and communicationshardware, and distribution of software tasks in the system,on the resulting control performance and functional safetyof the system. To conduct this study, we explored eight dif-ferent hardware topologies for the ACC system. Since eachof the eight dierent hardware architectures employed var-ious levels or redundancy, we also used the simulator toassess the failure modes of the architectures under intensefault injection. This data then formed the basis for a qual-itative estimation of dangerous failure rate.

9.4. Four hardware architectures

In the study presented here we considered systemsdesigns involving four dierent congurations of microcon-troller (shown schematically in Figs. 1316). In each casewe considered both single- and dual-bus designs: in total,therefore, eight dierent designs were assessed and com-pared in the present study.

In each case, the test system was created using InneonC167CS microcontrollers (one per node) running at a20 MHz oscillator frequency (Phytec, 2003). The nodeswere connected using 500 kbps twisted-pair CAN links.In each Figure, the various inputs and outputs to/fromeach node and the simulation are shown. From the fourFigures, it can be seen that the processor topologies aregrouped logically in each of the implementations. The Fig-

3 The reasons for distributing a control system over multiple processorsinclude modularity of design, safety and reduced wiring and harness costs(especially in the automotive sector). However, changes in the number ofprocessing elements to accommodate various forms of redundancy generally increases the overall system complexity and associated costs. Ofparticular concern in this case study is that changes in the number ofsystem nodes is likely to lead for example to changes in the time takento transmit information between system tasks. This can lead to variations

in transport delays in the control loop, and thereby degrade the controlperformance and stability (Franklin et al., 1994).ures also show how the various software tasks were distrib-uted in each architecture, with each task being allocated anumber: this will be explained further in Section 9.5.

In the most centralised architecture (Fig. 13), it can beseen that related control functions are grouped togetheron the same node: driver interface functions and associatedI/O are on one node; the ABS and TCS controllers andassociated I/O are on another node; and the ACC systemfunctionality and interfaces are on the Master node. Wethen progress through varying degrees of distribution untilthe last architecture, shown in Fig. 16. From this Figure itcan be seen that we have now partitioned the system due tophysical distribution around the vehicle, as opposed torelated control functions. Each wheel now has its own localABS controller; the pedal interface functions have beenseparated from the remaining driver interface functionslocated on the instrument cluster, and so on.

We can also see that the increase in the number of nodeshas enhanced the inherent fault tolerance of the system.For example, a single processor failure in the braking sub-system of the three node system can have a drastic eect,

Fig. 13. Three node architecture.

ms and Software 81 (2008) 11631183(Short and Pont, 2007a). The methodology allows theseamless integration of additional CAN channels into a

ysteM. Short, M.J. Pont / The Journal of Sdesign, and allows for fault-tolerant, time-triggered com-munications at high-levels of clock synchronisation.

9.5. Software and communication architecture

As mentioned in the introduction, it is generallyaccepted that highly predictable time-triggered behaviouris required for safety-critical systems such as these, for boththe network communications (e.g. Albert, 2004) and ECUtask scheduling (e.g. Bate, 1998). For these reasons, in this

Fig. 14. Six node

Fig. 15. Nine nod

Fig. 16. Ten nodems and Software 81 (2008) 11631183 1175case study we consider time-triggered designs based arounda shared-clock scheduler (Pont, 2001), using a ControllerArea Network (CAN) as the communication medium (Bos-ch, 1991). Please note that while CAN is often viewed as anevent-triggered architecture (Lean et al., 1999), it has beenshown that time-triggered behaviour can still be achievedusing a shared-clock protocol (Pont, 2001; Ayavooet al., 2007). We, therefore, employed a shared-clock proto-col for the present systems, and adapted the protocol toconform to the methodology described in (Short and Pont,

architecture.

e architecture.

architecture.

Internal RAM/register/stack validation; External RAM validation; ROM checksum; Peripheral test (e.g. ports, timer).

The overall approach to software fault-tolerance is illus-

Table 1System task list

Fig. 17. Approach to software fault tolerance.

1176 M. Short, M.J. Pont / The Journal of Systems and Software 81 (2008) 116311832007a) for the dual CAN systems. For each system consid-ered in this case study, we used the same tick interval(5 ms).

Table 1 shows the software tasks that were created toimplement the ACCS. Each task is allocated a number;please note that the same set of (periodic) tasks was exe-cuted in each system, with one exception. Specically, theLimp_home task is a safety-related task that is imple-mented only by a backup Master node: this task is not sup-ported in all four system architectures.

In Figs. 1316, the distribution of each of these tasks ineach of the hardware architectures can be seen. In additionto the high-level software tasks that were created for eachimplementation, given the critical nature of the system itwas required to design techniques for transient fault miti-gation into each system. These mechanisms included theuse of a 200 ms watchdog timer, duplex duplication of crit-

Task number Task name Period (ms)

1 Vehicle_Control_Update 1002 Vehicle_Speed_Update 103 Vehicle_Status_Update 504 ACC_Measurement_Update 105 Limp_Home_Update 1006 FLWheel_Speed_Update 107 FLWheel_Brake_Update 108 FRWheel_Speed_Update 109 FRWheel_Brake_Update 1010 RLWheel_Speed_Update 1011 RLWheel_Brake_Update 1012 RRWheel_Speed_Update 1013 RRWheel_Brake_Upodate 1014 Pedal_Detect_Update 1015 Throttle_Control_Update 1016 Driver_Display_Update 517 Driver_Action_Update 5ical data with comparison,4 sanity checks of control sig-nals, and the on-chip exception traps of the C167processor, listed below:

Stack overow; Stack underow; Illegal operand; Illegal word access; Protected instruction fault; Illegal bus access.

The unused areas of FLASH memory and RAM in eachdesign were lled with illegal operands to provide addedcontrol ow error detection. On activation of any of thesetraps, a full system reset of the microcontroller was forced.On system boot-up/reset, the microcontroller performedthe following software-based self-tests (Sosnowski, 2006):

4 The duplex data elds were checked before each use of the variable;any discrepancy forced a hardware reset.trated in Fig. 17. A number of techniques were alsoemployed during the software design process for each sys-tem, prior to experimentation. These included the adoptionof a structured programming technique, adherence to goodprogramming practice (MISRA, 2004; Holzmann, 2006)and use of a static code analysis tool.5 As a nal check(prior to the trials described here), each system wasrequired to run failure-free (and free of failed assertions)for a continuous period of 48 h using a simulation of abusy motorway.

9.6. Experimental methodology

In the present study, all architectures employed a samplerate of 10 Hz (Ts = 100 ms) for the main ACC controlalgorithm.

For each system, the time between sampling and controlactuation was rst measured during fault-free operation.This was achieved as follows. For each iteration of the con-

5 Please see www.splint.org for further details of the tool that was used.

re t

M. Short, M.J. Pont / The Journal of Systetrol loop, a port pin was set high at the start of the sam-pling task (for a short period of time). Another (initiallyhigh) pin was set low at the end of the actuate task, for ashort period.6 The signals from these two pins were thenAND-ed (using a 74LS08N), to give a pulse stream asshown in Fig. 18. The widths of the resulting pulses wasthus representative of the delay between the eectivesampling and actuation, and were measured using aNational Instruments data acquisition card NI PCI-6035E, used in conjunction with the LabVIEW 7.1 soft-ware package.

The sensor signals that were sampled, in each case, werethe vehicle speed, relative distance and relative velocity,with the pin state being set at the start of the rst samplebeing taken. The control signals that were refreshed duringmeasurement of the actuation tasks were the rear rightbrake control signal, and the throttle control signal. Ineach case, the pin state was set upon completion of the rel-evant task.

The measures of sample-actuation intervals provide uswith a useful indication of the impact that each architecturehas on basic system performance. However, we were par-ticularly interested in understanding how these basic timingmeasures would alter the control performance of the sys-tem. To measure the performance of each system, we usedthe IAE (Integral of Absolute Error) measure (Franklinet al., 1994). The IAE criterion is dened in Eq. (8), withT equal to the test duration.7

IAE Z T0

jetjdt 8

Fig. 18. Method used to measuFirstly, we recorded the IAE performance for a 300-s per-iod whilst each system was performing velocity control.During this period, the driver increases and decreasesthe setpoint from the initial value of 80.45 KPH(50 MPH) several times, via the buttons on the instrumentcluster. Secondly, the IAE performance was recorded foreach system during a 300-s period when performing dis-

6 These periods were selected specically to ensure that the maximumvalue of delay could be measured.7 Please note that although this measure is dependant on the test length

T, in this study all systems were tested for an identical duration of timeunder identical testing conditions; hence no further normalisation of thesubsequent results was required.tance control. Each distance test was performed whilst fol-lowing a lead vehicle, initially at 96.54 KPH (60 MPH).The lead vehicle makes a variety of manoeuvres duringthe test period, and the ACC vehicle attempts to maintaina distance corresponding to the desired time headway of1.5 s. The measures were accurately recorded on-line bythe simulation software.

We also used the facility to perform intensive fault injec-tion into each system. The experimental procedure for thiswas as follows. Each system was rst run for a continuousperiod of 100 h, during which time random hardware fail-ures were injected into system, using the rare events tech-nique. Each individual test run during this period wasstarted from random initial conditions, and all previousinjected faults were cleared. Each microcontroller was alsoissued with a full system reset prior to the commencementof a test run.

During each test run, the driver attempted to acceleratethe vehicle to a speed of 112.65 KPH (70 MPH). At thispoint the driver activates the ACC system. Following this,the driver then simply changes lanes and allows the ACCsystem to control the vehicle longitudinal motion; untilsuch point that the ACC system disengages. The ACC sys-tem will automatically disengage if it detects that at themaximum deceleration allowed by ISO specications, apreceding vehicle will come closer than 15 m. At this pointthe driver will take over, and again attempt to achieve thecruise speed and activate the ACC when the road becomesclear. The ACC system will also disengage if a fault isdetected, and issue a warning to the driver. At this pointthe driver will attempt to manoeuvre the vehicle into a safe

he delay times in each system.

ms and Software 81 (2008) 11631183 1177state, as described below.Each test run could end in one of two ways; either with

the vehicle entering a safe state, or a dangerous failureoccurring. A safe state could be reached if (and only if)the driver of the host vehicle brought the vehicle to a con-trolled rest on the hard shoulder of the motorway, inresponse to the system under test issuing a warning signalto indicate that integrity has been compromised. A danger-ous failure was classied as a either a vehicle collision, orthe vehicle becoming stranded (or otherwise totally out ofcontrol) for a given time period (30 s). The likelihood ratioduring this phase of testing was set at a = 106.

Following this, a further 100 h of testing was thenemployed. The overall test methodology during this period

was identical to that outlined above, with the exceptionthat each system was this time exposed to intense transientdisturbances (as opposed to hardware failures). A transientfailure was dened as a period between 5 and 500 ms dur-ing which time the system under test was subjected to a ser-ies of between 1 and 100 instantaneous bit ips. This waschosen to simulate a variety of disturbances, equivalentto a Single Event Upset (SEU), a nearby lighting strike

sample-actuate delays of each system during each experi-ment, are summarized in Table 3. The Table shows the

Fig. 19. Velocity control prole.

Fig. 20. Distance control prole.

Table 3Summary of system performance

System V IAE(MPH s)

D IAE(ms)

Throttle delay(ms)

Brake delay(ms)

3 Node x1 54.06 69.08 10.59 5.966 Node x1 55.44 90.23 20.06 25.819 Node x1 67.11 105.41 40.43 35.7210 Node x1 73.65 111.47 60.75 60.503 Node x2 54.11 69.06 10.61 5.986 Node x2 55.50 90.20 20.02 25.849 Node x2 67.03 105.50 40.43 35.7410 Node x2 73.66 111.41 60.74 60.54

1178 M. Short, M.J. Pont / The Journal of Systeor a persistent period of electromagnetic upset. Each nodewas assumed to be equally probable of being subjected to adisturbance during the period of the transient. Bit ips inthe C167 internal RAM (IRAM) areas can corrupt the sys-tem stack, registers, special function registers (SFRs) andprogram counter, whilst bit ips in the external RAM(XRAM) areas can corrupt the user stack and also the taskdata areas. Each fault injected in this study ipped a ran-dom bit in a random memory address location from a4.5 KB area of IRAM or a 4.5 KB area of XRAM; thusimplementing a wide variety of data, control ow andCPU/peripheral conguration errors. The likelihood ratioduring this phase of testing was set at a = 107.

The representative failure rates employed during thisperiod of experimentation are shown in Table 2, with val-ues derived from representative sources (Short et al.,2007; Short and Pont, 2007a). The statistical nature ofthe fault injection that was employed ensured that a hugenumber of dierent faults were injected with the vehiclein a variety of dierent representative road conditions.

9.7. Results

The results to be described in this section are split intotwo groups; velocity/distance control performance, andsample-actuate timings and safety integrity impacts. Webegin by describing the behaviour of each system duringthe control experiments.

9.7.1. Control and system timing

The velocity control prole that was used for eachexperiment is given in Fig. 19. The response shown is thatof the single-bus 10-node system. The distance control pro-le that was used for each experiment is given in Fig. 20.Again, the response shown is for the 10-node single-bussystem.

The actual values of both velocity (V) and distance (D)IAE recorded, along with the measurements of the eective

Table 2Component and event failure rates

Component/event Type Failure rate ( 106)

C167 CPU Permanent 0.76C167 RAM Permanent 0.25C167 ROM Permanent 0.16CAN link Permanent 1

CAN bus section Permanent 1Transient disturbance Intermittent 1ms and Software 81 (2008) 11631183average values that were recorded (each experiment wasrepeated ve times).

9.7.2. Fault injection

In this section we summarize the results that wererecorded during the fault-injection phases of the systemtesting. Detailed results of the hardware and software faultinjection are given in tabular form in Appendix A. For

trast, Fig. 22 shows an identical situation in which a back-up Master is employed (in the 10-node system). From thegure, it can be seen that the system recovers with enoughtime to decelerate the host vehicle and prevent a crash: thedriver, alerted to the fault by the warning signalled by theback-up node, then brings the vehicle to a safe state on thehard shoulder: in this case, system integrity is maintained.

9.7.3. DiscussionIt can be noted from Table 3 that for both the single-bus

and dual-bus systems, increasing the number of nodes inthe system decreases the overall control performance. Itcan also be seen from this table that a major factor in this

Table 4Summary of fault injection results

System kh Ph ks

3 Node x1 0.751 105 0.9825 1.006 Node x1 0.140 104 0.3727 1.009 Node x1 0.205 104 0.1539 1.0010 Node x1 0.227 104 0.0402 1.003 Node x2 0.115 104 0.2870 1.006 Node x2 0.210 104 0.1253 1.009 Node x2 0.305 104 0.0429 1.0010 Node x2 0.337 104 0.0000 1.00

0 5 10 15 20 250Time (s)

Fig. 22. Eect of loss of Master node (with back-up Master).

M. Short, M.J. Pont / The Journal of Systeeach system, we list the total number of test runs, the totalnumber of faults that were injected, the breakdown of thesefaults, and the classication of each test run into either asafe state or dangerous failure. Results are summarized inTable 4, were we quote the probability that a hardwarefault (Ph) or software transient fault (Ps) will result in adangerous failure in each system. We also show the equiv-alent (total) hardware (kh) and software transient failurerate (ks) for each system, calculated from the representativefailure rates that were given in Table 2. This then allows theestimation of total dangerous failure rate for each systemkd, using Eq. (9); this failure rate was used to classify theSIL that each system lies in, as shown in Table 4

kd kh P h ks P s 9

As an example of a dangerous failure, Fig. 21 shows the ef-fects of a master-node failure in the nine-node single-bussystem whilst following a lead vehicle. Due to the absenceof a back-up Master node, it can be seen that a collision oc-curs with a lead vehicle at 61.3 KPH (38.1 MPH). By con-

70

800 2 4 6 8 10 12 14 16 18 200

10

20

30

40

50

60

Time (s)

Target Distance (m)Target Velocity (mph)Host Velocity (mph)

Fig. 21. Eect of loss of Master node (without back-up Master).Ps kd SIL

106 0.0247 0.740 105 SIL1 106 0.0300 0.526 105 SIL1 106 0.0209 0.318 105 SIL1 106 0.0480 0.960 106 SIL2 106 0.0125 0.332 105 SIL1 106 0.0179 0.265 105 SIL1 106 0.0166 0.133 105 SIL1 106 0.0451 0.451 107 SIL3

10

20

30

40

50

60

70

80

Target Distance (m)Target Velocity (mph)Host Velocity (mph)

ms and Software 81 (2008) 11631183 1179degradation is the increase in the eective sample-actuatedelay for each system (as the number of nodes increases,the eective TDMA cycle time, and hence communicationdelays, also increases). Despite these performance varia-tions, all the system designs met their real-time specica-tion in this study. (If necessary, the performance of themulti-node system could have been improved using somesimple protocol modications: see Short et al., 2007; Aya-voo et al., 2007).

From these results, it is also apparent that the additionof the second (redundant) communication channel has hadno measurable eect on the system performance. This canbe mainly attributed to the fact that the methodology usedto implement this redundant channel has an almost

cle traveling down a three-lane motorway under free-ow-

motive control systems.

ystenegligible impact of the level of clock jitter that may beachieved using the shared clock protocol (Short and Pont,2007a).

Considering next the fault-injection results, it can beseen that adding extra nodes into a system decreases thedangerous failure rate kd, by reducing the probability Phthat a hardware failure will result in a dangerous failure.However, the overall probability of a hardware failure khincreases proportionally to this increase of processors andmay in some cases need to be taken into consideration.In addition, it can be seen that the addition of redundantprocessors also magnies the severity of transient distur-bances, with a large increase in the number of transientbit ips; this can be attributed to an increases in the mem-ory usage and computation requirements of the overall sys-tem, increasing its susceptibility. In general this has little (ifany) eect on the probability Ps that a transient distur-bance will lead to a dangerous failure when the additionalprocessors are Slave processors. However, in both singleand dual bus systems, the addition of a backup Master pro-cessor has a detrimental impact on this probability: we sug-gest that this is because the operation of the Master andbackup Master nodes is tightly synchronised and relativelycomplex, and therefore, more susceptible to short-term dis-turbances. It is important to stress, however, that this eectis more than compensated for by the increase in hardwarefault-tolerance that is gained by the addition of the backupMaster node; this is reected in the reduction in the prob-ability Ph that a hardware failure will result in a dangerousfailure in the 10 node systems.

Considering next the impact of the redundant busarrangement, it can clearly be seen that this a similar ben-ecial eect on the dangerous failure rate kd, again byreducing the probability Ph that a hardware failure willresult in a dangerous failure. Again, the overall probabilityof a hardware failure kh increases due to the increasednumber of hardware components in the system.

To summarize these results, it can be seen that the basicshared-clock mechanism, when complemented with thetransient fault detection mechanisms described in Section9.5, provides a level of reliability that may allow a systemto reach the SIL 1 level. With the addition of backup Mas-ter and Slave devices, this further increases the eective SILto 2. Finally, with the addition of a redundant communica-tion bus, a level of reliability commensurate with SIL 3may be achieved. In this case study, we conclude thatalthough each system met its functional performance spec-ication, only the 10-node, dual bus system had therequired level of reliability and fault tolerance to meet itsfunctional safety requirements when subjected to the faultsand failures considered in this study.

10. Conclusions and further work

In this paper, the development of a novel, low-cost and

1180 M. Short, M.J. Pont / The Journal of Sexible real-time HIL simulator for use in the develop-ment and assessment of automotive embedded controlFrom the results obtained in the specic case studydescribed here, it can be seen that the use of the HIL sim-ulator has allowed us to rigorously assess the impact ofadopting dierent hardware congurations on the controlperformance and safety integrity of an ACC system.Since safety arguments in practice are as distinct as theapplication areas they are employed in, it is dicult toprovide generalised results regarding safety concepts.However we believe that this facility described in thispaper has allowed us to provide recommendationsregarding system reliability and fault tolerance (whichare closely related to safety) to prospective designers ofautomotive systems.

It should be noted that the work described in this paperhas been limited to discussions of vehicular longitudinalcontrol. With increasing interest in concepts such assteer-by-wire and automatic lane keeping, there is a needto extend this analysis to consider to more complex situa-tions such as lateral vehicle control and vision-basedsystems. We suggest that the basic simulator frame-work presented in this paper may provide a basis for suchfuture work, giving system designers the means to e-ciently and rapidly extract a reliable source of empiricalevidence related to a wide range of embedded-systemapplications.

Acknowledgements

The work described in this paper was supported by theLeverhulme Trust (Grant F/00 212/D). An early descrip-tion of the test facility described in this paper was presentedat the eighth International IEEE Conference on IntelligentTransportation Systems in Vienna, September 2005 (Shortand Pont, 2005). Initial versions of the test results discussedin Section 9.7 were presented at the SAE World Congress2006 (Short et al., 2007).

Appendix Aing trac conditions. We have presented macroscopicsimulation data of the trac ows which suggest thatthe test facility provides a realistic representation of a par-ticular section of motorway in the UK. We havedescribed how fault injection may be incorporated intothe simulator, and have described how the resulting fail-ure modes may be automatically classied. Through theuse of a case study we have illustrated the use of the sim-ulator, and shown that it is an eective means of examin-ing both the functional behaviour and the functionalsafety and reliability of dierent possible designs for auto-systems has been described. We have detailed how thistest facility has been congured to represent a road vehi-

ms and Software 81 (2008) 11631183Summary of hardware and software fault injectionresults

BysteSystem Hardware faults injected

Total Node CAN Link1

CAN Link2

CAN1

3 Node x1 684 304 277 0 1036 Node x1 1151 562 509 0 809 Node x1 1715 882 756 0 7710 Nodex1

1865 940 850 0 84

3 Node x2 965 274 260 264 856 Node x2 1700 548 489 513 659 Node x2 2307 780 680 697 7510 Nodex2

2647 858 716 882 87

System Software faults injected

M. Short, M.J. Pont / The Journal of SReferences

Albert, A., 2004. Comparison of event-triggered and time-triggeredconcepts with regard to distributed control systems. Proceedings ofEmbedded World, vol. 1719. Nurnberg, Germany, pp. 235252.

Analogue Devices, 1998. AD7394 Data Sheet, Analogue Devices,Norwood, MA, USA.

Arlat, J., Aguera, M., Amat, L., Crouzet, Y., Fabre, J.-C., Laprie, J.-C.,Martins, E., Powell, D., 1990. Fault injection for dependabilityvalidation a methodology and some applications. IEEE Trans.Software Eng. 16 (2), 166182.

Arlat, J., Costas, A., Crouzet, Y., Laprie, J-C., Powell, D., 1993. Faultinjection and dependability evaluation of fault-tolerant systems. IEEETrans. Comput. 42 (8), 913923.

AutoSim, 2007. Driving Research Simulators, , (accessed July 2007).

Ayavoo, D., Pont, M.J., Short, M., Parker, S., 2007. Two novel shared-clock scheduling algorithms for use with CAN-based distributedsystems. Microprocess. Microsyst. 31 (5), 326334.

Bakker, E., Pacejka H., Lidner, L., 1989. A new tire model withapplication in vehicle dynamic studies, SAE Paper No. 890087, pp.101113.

Bate, I.J., 1998. Scheduling and timing analysis for safety critical real-timesystems, Ph.D. dissertation, Department of Computer Science, Uni-versity of York, UK.

Bosch, 1991. CAN Specication Version 2.0, Robert Bosch GmbH.Bullock, D., Johnson, B., Wells, R.B., Kyte, M., Li, Z., 2004. Hardware-

in-the-loop simulation. Transport. Res. Part C 12, 7389.

Number of transients Total bits ipped

3 Node x1 6080 928076 Node x1 6135 1837659 Node x1 6132 27778710 Node x1 6191 3086653 Node x2 6086 917306 Node x2 6160 1873349 Node x2 6218 28009310 Node x2 6181 311179Recorded failures Estimatedvalues

us CAN Bus2

Dangerous Safestates

kh 106 Ph

0 672 12 7.51 0.9820 429 722 14.02 0.3730 264 1451 20.53 0.1540 75 1790 22.70 0.040

82 277 688 11.51 0.28785 213 1487 21.02 0.12575 99 2208 30.53 0.043104 0 2647 33.70 0.000

Recorded failures Estimated values

ms and Software 81 (2008) 11631183 1181Butler, R.W., Finelli, G.B., 1993. The infeasibility of quantifying thereliability of life-critical real-time software. IEEE Trans. Software Eng.19 (1), 312.

Cole Jr, J.S., Jolly, A.C., 1996. Hardware-in-the-loop simulation at the USArmy Missile Command, In: Proceedings of SPIE Vol. 2741: Tech-nologies for Synthetic Environments: Hardware-in-the-Loop Testing,pp. 1419.

Courage K., Lee, S., 2005. Hardware in the loop Trac Simulation: FinalReport, University of Florida, Report No. UFTRC-965-1.

DFT, 2003. Road Trac Statistics: 2003, Transport Statistics BulletinSB(03)26, The Department For Transport, UK, July 2003.

DFT, 2004. Vehicle Speeds In Great Britain: 2003, Transport Statis-tics Bulletin SB(04)29, The Department For Transport, May2004.

Ellims, M., 2000. Hardware in the loop testing, In: Proceedings ofIMECHE Symposium IEE Control 2000, Cambridge, UK, September2000.

Fancher, P., Ervin, R. Sayer, J., Hagan, M., Bogard, S. Bareket, Z.,Meord, M., Haugen, J., 1998. Intelligent Cruise Control FieldOperational Test: Final Report, University of Michigan, Ann Arbor,Transportation Research Institute, UMTRI-98-17, July 1998.

Fang, X., Pham H.A., Kobayashi, M., 2001. PD controller for carfollowing models based on real data, In: First Human-CenteredTransportation Simulation Conference, Iowa City, Iowa, November47, 2001.

Franklin, G.F., Powell, J.D., Emani-Naeini, A., 1994. Feedback Controlof Dynamic Systems, third ed. Addison-Wesley, Reading,Massachusetts.

Dangerous Safe states ks 106 Ps150 16 1.00 0.025184 81 1.00 0.030128 136 1.00 0.021297 125 1.00 0.04876 99 1.00 0.012110 201 1.00 0.018103 323 1.00 0.017279 301 1.00 0.045

ysteGillespie, T., 1992. Fundamentals of Vehicle Dynamics. Society ofAutomotive Engineers (SAE) Press Inc..

Gipps, P.G., 1986. A model for the structure of lane-changing decisions.Transport. Res. 20B (5), 403414.

Gomez, M., 2001. Hardware-in-the-loop simulation, In: EmbeddedSystems Programming, vol. 14, No. 13.

Hakiwara, K., Terayama, S., Takeda, Y., Yoda, K., Suzuki, S., 2002.Development of automatic transmission control system using hard-ware-in-the-loop simulation system. JSAE Rev. 23, 5559.

Hammett, R., 2002. Design by extrapolation: an evaluation of faulttolerant avionics. IEEE AESS Systems and Magazine.

Hecht, M., Hecht, H., 2000. Use of importance sampling and relatedtechniques to measure very high reliability software, In: Proceedings ofIEEE Aerospace 2000 Conference, Big Sky, MT, March, 2000.

Heidelberger, P., 1995. Fast simulation of rare events in queuing andreliability models. ACM Trans. Model. Comput. Simulat. 5 (1), 4385.

Hollingwood, J., Buttereld, D., Swart, B., Allsop, J., 2001. C++BuilderTM 5 Developers Guide. Sams Publishing.

Holzmann, G.J., 2006. The power of ten: rules for developing safetycritical code. IEEE Comput. 39 (6), 9395.

Iserman, R., Schwarz, R., Stoltz, S., 2002. Fault-tolerant drive-by-wiresystems. IEEE Control Syst. Mag. 22 (5), 6481.

ISO, 2003. Adaptive cruise control systems performance requirementsand test procedures, International Standards Organization, Standardnumber 15622, Geneva, Switzerland.

Kendall, I.R., Jones, R.P., 1999. An investigation into the use ofhardware-in-the-loop simulation testing for automotive electroniccontrol systems. Control Eng. Practice 7, 13431356.

Lean, G., Heernan, D., Dunne, A., 1999. Digital networks in theautomotive vehicle. IEE Comput. Control Eng. 10 (6), 257266.

Levenson, N.G., 1995. Safeware: System Safety and Computers. Addison-Wesley, Reading, MA.

Li, J., Yu, F., Zhang, J.W., Feng, J.Z., Zhao, H.P., 2002. The rapiddevelopment of a vehicle electronic control system and its applicationto an antilock braking system based on hardware-in-the-loop simula-tion. Proc. Inst. Mech. Eng. Part D: Automobile Systems 216, 95105.

Li, Q., Whitely, J.R., Rhinehart, R.R., 2003. A relative performancemonitor for process controllers. Int. J. Adapt. Control Signal Process.17, 685708.

Lutz, R.R., Mikulski, I.C., 2003. Operational anomalies as a cause ofsafety-critical requirements evolution. J. Syst. Software 65, 155161.

Mathworks, 2007. Automotive Embedded System Design, WWW Page:, (accessed July 2007).

McDonald, M., Brackstone M., Jeery, D., 1994. Simulation of lane usagecharacteristics on 3 lane motorways, In: Proceedings of the 27thISATA Conference, Aachen, Germany, pp. 365372.

Microsoft Corporation, 1998. About multimedia timers, MicrosoftMSDN Library, Platform SDK.

MISRA, 2001. Report 2 Integrity, Motor Industry Software ReliabilityReport, Released February 2001.

MISRA, 2004.Guidelines for the use of the C language in vehicle basedsoftware, Motor Industry Software Reliability Report, October 2004.

Olsen, E.C.B., Lee S.E., Wierville, W.W., 2002. Analysis of distribution,frequency, and duration of naturalistic lane changes, In: Proceedingsof the 46th Human Factors and Ergonomics Society, Baltimore, USA,17891793, September 2002.

Paramics, 2007. Paramics: Overview, WWW Page, , (accessed July 2007).

Phytec, 2003. phyCORE 167CS Hardware Manual, Phytec, April 2003.Pont, M.J., 2001. Patterns for Time-triggered Embedded Systems:

Building Reliable Applications with the 8051 Family of Microcon-trollers. ACM Press/Addison-Wesley Publishing.

Pont, M.J., Norman, A.J., Mwelwa C., Edwards, T., 2003. Prototypingtime-triggered embedded systems using PC hardware, In: Proceedingsof EuroPLoP 2003, Germany, June 2003.

1182 M. Short, M.J. Pont / The Journal of SSAE, 1993a. Class C Application Requirement Considerations, SAERecommended Practice J2056/1, SAE, June 1993.SAE, 1993b. Survey of Known Protocols, SAE Information ReportJ2056/2, SAE, April 1993.

Short, M., Pont, M.J., 2005. Hardware in the loop simulation ofembedded automotive control systems, In: Proceedings of the 8thIEEE International Conference on Intelligent Transportation Systems(ITSC 2005), Vienna, Austria, 1316 September 2005, pp. 226231.

Short, M., Pont, M.J., 2007a. Fault-tolerant time-triggered communica-tion using CAN. IEEE Trans. Ind. Inform. 3 (2), 131142.

Short, M., Pont, M.J., 2007b. Accelerated Fault Injection Testing OfDistributed Embedded Systems, University of Leicester, TechnicalReport ESL 07-04, March 2007.

Short, M., Pont, M.J., 2007c. Verication And Validation Of The HILTest Facility, University of Leicester, Technical Report ESL 07-05,March 2007.

Short, M., Pont M.J., Huang, Q., 2004a. Simulation of vehicle longitu-dinal dynamics, Technical report ESL 04/01, Embedded SystemsLaboratory, University of Leicester.

Short, M., Pont M.J., Huang, Q., 2004b. Simulation of motorway tracows, Technical report ESL 04/02, Embedded Systems Laboratory,University of Leicester.

Short, M., Pont M.J., Huang, Q., 2004c. Control technologies forautomotive drive-by-wire applications, Technical report ESL 04/04,Embedded Systems Laboratory, University of Leicester.

Short, M.J., Fang, J., Pont, M.J., Rajabzadeh, A., 2007. Assessing theimpact of redundancy on the performance of a brake-by-wire system.SAE Trans.: J. Passenger Cars (Electronic and Electrical Systems) 115(7), 331338.

Sosnowski, J., 2006. Software-based self-testing of microprocessors. J.Syst. Architect. 52, 25727