Final Thesis

Simulation of a Distributed

Implementation of an Adaptive

Cruise Controller

by

Pontus Riis

LITH-IDA/DS-EX--07/007--SE

13th June 2007

Simulation of a DistributedImplementation of an Adaptive Cruise

Controller

Final Thesis

performed at Embedded Systems Laboratoryin the Department of Computer and Information Science

at Linkoping University

by

Pontus Riis

LITH-IDA/DS-EX--07/007--SE

13th June 2007

Supervisor: Soheil Samii

Department of Computer andInformation Scienceat Linkoping University

Examiner: Prof. Petru Eles

Department of Computer andInformation Scienceat Linkoping University

Abstract

Much functionality of today’s vehicles runs as software on embedded com-puter systems. This includes, for example, automatic climate control andengine control. As the processors necessarily are located in diffent physicallocations inside the vehicle wires must be drawn between processors thatneed to communicate. Therefore, it is typical to have one or several busesconnecting the processors in an embedded computer network, thus creatinga distributed system. As some parts of the system in the car have real-time properties, it is necessary to validate that the real-time properties areupheld in the distributed system.

This thesis presents the design and implementation of an adaptive cruisecontroller (ACC), which is a cruise controller that also keeps a minimum dis-tance to the closest vehicle in front. Further, the performance of the ACChas been evaluated using an existing system-level simulator for distributedreal-time systems together with metrics for Quality-of-Control (QoC).

The ACC has then been simulated under different scenarios. The sce-narios include outside conditions, for example the slope of the road, thebehaviour of the vehicle in front, and the desired velocity, as well as inter-nal conditions as adding different amounts of extra load on the processorsand the bus.

The results show that the functionality of the ACC starts deterioratingwhen the extra load on the nodes reaches high levels. When the extraload reaches very high levels, the ACC stops functioning completely. Theresults also show that the extra load on the bus has very little effect on theperformance of the ACC.

iii

Preface

About the Thesis

This thesis was written as the final project of the “Master of Science inComputer Science and Engineering Programme” at Linkoping Universityin Sweden. The work presented in this thesis was performed at EmbeddedSystems Laboratory (ESLAB), a research laboratory in the Department ofComputer and Information Science at Linkoping University. The intendedaudience is people who are studying or have studied basic computer scienceand electronics.

Examples and figures are numbered according to their order in eachchapter. References in the text are given in square brackets and can befound in the end of the thesis. Moreover, the document was typeset inLATEX. The figures are created with XFig and Gnuplot.

Acknowledgements

Thanks to my family, who has always supported me, my supervisor, SoheilSamii, who has been an invaluable help in the making of this thesis andmy examiner, Prof. Petru Eles. I would also like to thank Per Oberg ofVehicular Systems at the Dept. of Electrical Engineering, for helping meget a working car model for the thesis.

Pontus RiisLinkoping, Spring 2007

v

Contents

1 Introduction 11.1 Real-Time Embedded Systems . . . . . . . . . . . . . . . . 11.2 Adaptive Cruise Controller . . . . . . . . . . . . . . . . . . 31.3 Problem Definition . . . . . . . . . . . . . . . . . . . . . . . 41.4 Thesis Overview . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Preliminaries 52.1 Application Model . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.1 Process . . . . . . . . . . . . . . . . . . . . . . . . . 52.1.2 Process Graph . . . . . . . . . . . . . . . . . . . . . 6

2.2 System Architecture . . . . . . . . . . . . . . . . . . . . . . 72.2.1 Hardware Architecture . . . . . . . . . . . . . . . . . 72.2.2 Software Architecture . . . . . . . . . . . . . . . . . 8

2.3 The Controller Area Network . . . . . . . . . . . . . . . . . 11

3 Design 153.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.2 ACC Functionality . . . . . . . . . . . . . . . . . . . . . . . 153.3 System Overview . . . . . . . . . . . . . . . . . . . . . . . . 163.4 Logical Architecture . . . . . . . . . . . . . . . . . . . . . . 16

3.4.1 Inner Loop . . . . . . . . . . . . . . . . . . . . . . . 173.4.2 Outer Loop . . . . . . . . . . . . . . . . . . . . . . . 18

3.5 Modelling the Environment . . . . . . . . . . . . . . . . . . 193.5.1 Car Model . . . . . . . . . . . . . . . . . . . . . . . 193.5.2 Road . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.5.3 Other Cars . . . . . . . . . . . . . . . . . . . . . . . 21

4 Implementation 234.1 Modelling the ACC . . . . . . . . . . . . . . . . . . . . . . . 23

4.1.1 Logical Architecture . . . . . . . . . . . . . . . . . . 234.1.2 Process Graph and Mapping to Nodes . . . . . . . . 24

4.2 Car Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.3 Approximations . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.3.1 Inner Loop . . . . . . . . . . . . . . . . . . . . . . . 26

vii

viii Contents

4.3.2 Outer Loop . . . . . . . . . . . . . . . . . . . . . . . 274.3.3 Road . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.3.4 Other Cars . . . . . . . . . . . . . . . . . . . . . . . 28

4.4 Background Processes . . . . . . . . . . . . . . . . . . . . . 28

5 Experiments 315.1 Experiment Setup . . . . . . . . . . . . . . . . . . . . . . . 315.2 Performance Metric . . . . . . . . . . . . . . . . . . . . . . 335.3 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.3.1 Cruise Controller . . . . . . . . . . . . . . . . . . . . 355.3.2 Adaptive Cruise Controller . . . . . . . . . . . . . . 375.3.3 Background Load on the CC . . . . . . . . . . . . . 395.3.4 Background Load on the ACC . . . . . . . . . . . . 43

5.4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

6 Conclusions and Future Work 516.1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . 516.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Bibliography 53

Chapter 1

Introduction

This chapter starts with a general introduction to real-time embedded con-trol systems and follows it up with an example application. Then we willdiscuss the implementation of these applications on distributed systems,and further describe the problem that is addressed in this thesis, namelythe implementation of an adaptive cruise controller simulator.

1.1 Real-Time Embedded Systems

There are many different definitions of what constitutes an embedded sys-tem. One definition by Wolf [16] is that it is any device that includes aprogrammable computer but is not itself intended to be a general-purposecomputer. This means that a PC is not an embedded system but a cellphone is. As microprocessors have gotten cheaper, smaller, and more pow-erful, more and more applications have been built as embedded systems.

A characteristic of an embedded system is that it interacts continuouslywith its environment, which in turn leads to embedded systems often havingreal-time behaviour. This means that the correctness of the system dependsnot only on the logical results of the computations, but also on the physicalinstant at which these results are produced [10]. The computations are doneby processes. The latest instant at which the results of a process must beproduced is called the deadline of the process. Real-time systems can bedivided into either soft or hard real-time. Hard real-time means that thedeadlines must never be missed, otherwise the consequences can be severe.In soft real-time systems, deadlines can be missed without very seriousconsequences, but the performance of the system is degraded.

To guarantee real-time functionality we must have strict control ofhow processes are scheduled. There are two main approaches for schedul-ing, time-triggered (TT) and event-triggered (ET) scheduling. With TTscheduling the starting time of processes is determined at the design ofthe system, while with ET scheduling the starting time of processes is de-termined as the system is running, depending on incoming events. Some

1

2 Introduction

systems, for example a cardiopulmonary monitor, are run periodically in-dependently of changes in the environment. For such systems it is suitableto use TT scheduling. Some other systems, for example an airbag, are runin reaction to events in the system’s environment. For those systems, ETscheduling is suitable.

Some embedded systems, for example airplanes and automobiles, are,by their nature, distributed systems, with several computation nodes, lo-cated in different physical locations inside the vehicle. A computation nodetypically consists of a central processing unit (CPU), random access mem-ory (RAM), I/O interfaces and a network interface. [15]

The application is often divided into subparts and implemented onthis distributed embedded system. Often this creates data dependenciesbetween the computation nodes, leading to communication via the com-puter network. We will focus on bus-based communication in this thesis.Analagous to how processes are scheduled, the bus communication mustalso be controlled to ensure that the real-time functionality of the systemis upheld. To assure this we can use different medium access protocolson the bus. These protocols can, just as the scheduling for processes, bedivided into time-triggered and event-triggered protocols. With TT proto-cols all messages are sent at times determined at the design of the system,while with ET protocols the processes try to send when they are ready, andthe protocol handles conflicts.

Examples of protocols used in real-time distributed systems are Time-Triggered Protocol (TTP) [5], which is TT, and Controller Area Network(CAN) [4] which is ET. The reason why arbitrary, widely used protocols,such as Ethernet, are not used in real-time systems, is that it is not possibleto bound the worst-case communication delay. To clarify the definitions inthis section, Example 1.1 will show a car with its distributed embeddedsystem.

Example 1.1: Applications that are run by microcontrollers in a moderncar range all the way from audio systems and automatic climate controlto engine and brake control, as described by Johansson et al. [9]. Fig-ure 1.1 shows a car equipped with several computation nodes connectedvia a bus. The Human-Machine Interface (HMI) node is handling the in-strument panel that the driver interacts with. The Velocity node measuresthe angular velocity of the car’s wheels and converts it into the velocityat which the car is driving. To be able to show the driver the velocity atwhich the car is driving, the value of the velocity must be transferred fromthe Velocity node to the HMI node. To do this the Velocity node sendsthe velocity over the bus regularly at a constant frequency. The HMI nodereceives the value and shows it to the driver via the instrument panel.

As the system is distributed, several applications might be present onthe same node, and all applications will be sending over the same bus. As

1.2 Adaptive Cruise Controller 3

some applications have real-time requirements this poses a challenge to thedesigner of the system.

Bus

Velocity node

Human−Machine Interface (HMI) node

Figure 1.1: A simplified view of an embedded computer network archi-tecture in a car facing right, viewed from above

A common problem is having to control a signal indirectly, for examplecontrolling the temperature in a room by adjusting the radiator. Adjustingthe radiator without knowing the temperature is very difficult, since thetemperature is depending on many other factors, for example the outsidetemperature. The common solution to this problem is having a feedbackcontroller [8], as the one depicted in Figure 1.2. The controller gets areference signal, that it controls towards, and the out signal from the plant.

Controller Plant

−1

Referencesignal r r−y In signal Out signal y∑

Figure 1.2: A generic feedback controller

1.2 Adaptive Cruise Controller

Many modern cars and trucks are equipped with a cruise controller (CC). Itis a system that, when activated, keeps the vehicle at a constant velocity,set by the driver. This system is usually used on the highway, where itis common to cruise at a constant velocity for long periods of time, asa relief for the driver. The adaptive cruise controller (ACC) is a moreadvanced version of a regular cruise controller. Instead of only controlling

4 Introduction

the velocity, it also measures the distance to the closest vehicle in front andmaintains a given minimum distance or time headway. Ideally, the driveronly has to control the steering and only interrupts the ACC at takeoversor situations that might lead to accidents.

1.3 Problem Definition

The goal of this thesis is to design and implement an adaptive cruise con-troller, as a distributed application and further run it on an existing system-level simulator for distributed real-time systems and study its performance.To test the application a vehicle will also be modelled and implemented inthe simulator. The application’s performance will be measured under dif-ferent scenarios and load conditions using different metrics. The followingvariables will be adjustable:

• Desired velocity

• The road

• Behaviour of vehicle in front

• Background load on the nodes from processes not belonging to theACC

• Background load on the bus from processes not belonging to the ACC

1.4 Thesis Overview

The rest of this thesis is organized as follows:

• Chapter 2 describes the general modelling of real-time embedded sys-tems and applications that is required to understand this thesis

• Chapter 3 describes the design of the ACC and its surroundings

• Chapter 4 describes the implementation process

• Chapter 5 consists of an experimental evaluation of the ACC and itsresults

• Chapter 6 concludes the thesis and points out possible directions forfuture work

Chapter 2

Preliminaries

To simplify embedded system design, certain abstractions are necessary.Instead of looking at the lowest hardware level, we design using abstrac-tions, which describe higher-level properties of the system. The abstractionlevel we work at and what properties of the system are of particular interestwill be explained in this chapter.

Before we design the system we must know what requirements are puton the system. The requirements can be divided into functional and non-functional. Nonfunctional requirements include performance, cost, physicalsize, weight and power consumption, among others. Functional require-ments are demands regarding the system’s functionality. For example acell phone should ring when someone is calling you and a microwave ovenshould heat the food according to the user’s settings.

This thesis will focus on a system’s performance and what effects it hason functional requirements. Physical properties such as cost, physical sizeand power consumption will be ignored.

2.1 Application Model

The application model aims at describing a system’s functionality. In thisthesis we will use a general model common in real-time systems design,the process graph. We assume that a real-time application consists of aset of software processes. Certain processes might be data-dependent onother processes, for example the Human-Machine Interface in a car mustreceive the velocity from another process in order to show it to the driver.The decisions on how many processes to use to describe the applicationand what functionality to put in each process is a decision taken by thedesigner of the system.

2.1.1 Process

Since the system has real-time constraints, the processes are modelled withboth functional and temporal properties. The functional properties of a

5

6 Preliminaries

process can be described as a function f : X → Y where X is the inputdomain and Y is the output domain. Example 2.1 describes a simple processand its functional properties.

Example 2.1: We have a process f , which takes an integer x as inputand outputs the square of x as well as the square root. The functionalbehaviour of f can be described by a function f : N → N × [0,∞[ wheref(x) = (x2,

√x).

The temporal properties of a process are as listed:

Best-case execution time (BCET) The minimum amount of time theprocess will take to execute.

Worst-case execution time (WCET) The maximum amount of timethe process will take to execute.

Deadline The time at which the process is supposed to have finished ex-ecuting. A hard real-time system is considered to have failed if thedeadline is ever missed. In a soft real-time system the result of theprocess might be discarded or be less valuable if the deadline is passed.

Period Processes are event-triggered. In this thesis we assume that theevents triggering process releases are occuring periodically.

Offset The offset, relative to the period, that the process starts at. Can beeither static or dynamic. A static offset means the offset is a constantvalue, while a dynamic offset means the offset varies inside a range.

The best-case and worst-case execution time depends on the function-ality of the process, the code structure, the input data and the platform onwhich the process is run. To determine the values, the code is run throughspecial analysis tools [12].

Each process also has a number of input buffers and a number of outputbuffers. When the process starts executing it takes its input values fromthe input buffers. At the end of its execution it writes to its output buffers.

2.1.2 Process Graph

To describe the entire application, it is not enough to describe each processin isolation. We need also to model the data dependencies between theprocesses. To do this we use a process graph, as depicted in Figure 2.1.

S1 and S2 are sensors that fetch information from the surrounding en-vironment. A1 is an actuator that actuates the commands given from theapplication. If we compare the process graph to the generic feedback con-troller from Section 1.1, the actuator, A1, is the plant, and the rest of the

2.2 System Architecture 7

P1

P2 P3

P4

S1 S2

A1

Output buffers

Input buffers

Controller

Plant

Figure 2.1: Process graph

process graph is the controller. The vertices P1 to P4 are processes. Theedges between outputs and inputs indicate the data dependencies. In Fig-ure 2.1 this means, for example, that process P2 is dependent on sensor S1and process P1. This means that process P2 cannot execute until it getsthe values from sensor S1 and process P1.

2.2 System Architecture

Now that we have an application model we also need to elaborate an ab-stract model of the system architecture.

2.2.1 Hardware Architecture

Since we are dealing with a bus-based distributed system we will have manyindependent computation nodes that communicate with each other througha bus. Each such computation node consists of a CPU, some combinationof RAM/ROM, and a network interface for communication [15]. Some willalso have direct communication with sensors and actuators. Figure 2.2shows an example with three computation nodes that are connected via abus.

Each process in the application is then mapped to one of the computa-tion nodes. Figure 2.3 shows how an application has been mapped to thesystem in Figure 2.2. The vertices indicate the application’s processes, and

8 Preliminaries

CPU

I/O INTERFACE

Node NodeNode

sensors actuators

Communication controller

RAM

ROM

Bus

Figure 2.2: A bus-based computer network

the edges indicate the data dependencies between the processes.

P5 P8 P9

P7 P4P1

P2

P3

P6

Figure 2.3: An application mapped on an architecture consisting of 3computation nodes

2.2.2 Software Architecture

In Figure 2.4 a computation node is depicted. As can be seen, there is anapplication layer and a network interface. The application layer consists ofa real-time kernel that handles the running of processes and data passingbetween processes. The network interface handles messages being sent overthe bus.

The real-time kernel has three main objectives:

• Starting and stopping processes

• Writing data to input buffers

2.2 System Architecture 9

PP

P

Node

ActuatorsSensors

RT−kernel

Communicationcontroller

App

licat

ion

leve

l

Bus

inte

rfac

e

Net

wor

k

Figure 2.4: Software example

• Sending messages

There are two different ways for the RT-kernel to decide when to startand stop processes. Either the processes are time-triggered (TT) or event-triggered (ET). Time-triggered processes are scheduled to run at certaintimes, while for event-triggered processes the scheduling is done online as aresponse to events. If the processes are TT, static cyclic scheduling (SCS)is used. The cyclic part means all processes are run periodically, with a setperiod. Static scheduling means all scheduling is done at design time. Eachprocess is given a time, relative to the period, for when it is to be started.Thus, we have a schedule table which is stored in the memory of the node.The schedule table contains a list of all processes that are mapped to thenode and their respective starting times. The schedule table is used by adispatcher that starts processes (for example see Figure 2.5).

Time Process

2

5 ms

20 ms

25 ms

1

3

Dispatcher

Period = 50 msSchedule table

Figure 2.5: TT scheduling

If the processes are ET, the scheduling is done as the application is

10 Preliminaries

running. To determine when a process is allowed to run, a synchronizer isused. The synchronizer is also responsible for writing data to input buffers.When all data dependencies of a process has been fulfilled, the synchronizerreleases the process to the scheduler. Since the scheduler can get severalprocesses at once, it must decide which one will be run first. This decision isdone by assigning each process a unique priority. The priorities can eitherbe static or dynamic. Static priorities are decided at design time whiledynamic priorities are decided as the application is running. Examples ofstatic priority schemes are Rate Monotonic (RM) [11], where the processwith the shortest scheduling rate is given the highest priority and FixedPriority Scheduling (FPS) where all prioritites are set by the designer. Anexample of a dynamic priority scheme is Earliest Deadline First (EDF) [11],where the process whose deadline is closest to expiring is given the highestpriority.

ET scheduling is either preemptive or non-preemptive. If the schedul-ing is preemptive it means that a lower priority process that is running canbe interrupted by a higher priority process that is scheduled to run. Thelower priority process’ state is saved and the running of the process is sus-pended until the higher priority process is finished. With non-preemptivescheduling any process that is running will continue running until finishedregardless of other processes. Example 2.2 shows an application being runwith both FPS and EDF and illustrates the difference it makes. Both casesare run with preemptive scheduling.

Synchronizer

Scheduler

Process

graph

Figure 2.6: ET scheduling

Example 2.2: Our example application consists of six processes and hasthe process graph depicted in Figure 2.7. Figure 2.8 shows a table with theoffset, execution time and relative deadline being given for each process.To illustrate how the processes are being run using FPS scheduling, a socalled Gantt chart is depicted in Figure 2.9. The priority of each process islisted on the left side. It is assumed that one single processor is executing

2.3 The Controller Area Network 11

P4 P5

P6P2

P1

P3

Figure 2.7: Application process graph

Process Offset Exec.time (ms)

1

2

3

4

5

6

5

30

20

10

20

50

10

20

10

5

15

5

Deadline

20

80

35

20

50

70

Figure 2.8: Process values

all processes. The boxes with patterns are indicating when a process isrunning, the white boxes indicate that a process is waiting to run.

���������������

���������������

������������������������������

������������������������������

���������������

���������������

���������

���������

���������

���������

���������

���������

���������������

���������������

10 20 30 40 50 60 70 80

6

4

5

2

3

1

Prio

rity

Missed deadlines

P6

P5

P4

P3

P2

P1

Figure 2.9: Gantt chart for FPS scheduling

As we can see in the figure, processes 3 and 5 both miss their respec-tive deadlines. Now we run the application using EDF scheduling instead.Figure 2.10 depicts a Gantt chart for the application using EDF schedul-ing. The priority of each process is determined dynamically depending onits deadline. Notice how the order in which the processes run is changedcompared to FPS scheduling, and how all processes finish before their dead-lines. Since our application is real-time this means that the behaviour ofthe application might change depending on the scheduling policy. There-fore it is important to consider which scheduling scheme should be usedwhile designing a real-time application.

2.3 The Controller Area Network

Since we are designing a real-time distributed system we need a communi-cation protocol that can guarantee correct real-time behaviour on the bus.This section will describe the communication protocol that we will use.

12 Preliminaries

���������������

���������������

���������

���������

������������������������

������������������������

���������������

���������������

���������

���������

������������������������

������������������������

���������

���������

10 20 30 40 50 60 70 80

P6

P5

P4

P3

P2

P1

Figure 2.10: Gantt chart for EDF scheduling

The Controller Area Network (CAN) [4] protocol was developed byBosch and Intel in the mid-1980s. It was first introduced in standardcars in the early 1990s by Mercedes. More details on the CAN protocolcan be found, for example, in [7]. CAN has an event-triggered schedulingpolicy, that employs a collision avoidance mechanism. If two nodes try totransmit at the same time, the node that sends the frame with the highestpriority wins, and the other node insted recieves the message and tries tosend its message when the bus is free again. Each frame has an identifiercorresponding to a unique priority that is transmitted in the arbitrationfield, which is in the first bits of the frame. To ensure data correctnesseach frame also contains a CRC field and an acknowledgement (ACK) field.For a clearer view, see Figure 2.11. Example 2.3 shows a small distributedapplication using CAN.

Data field, up to 8 bytes

Arbitration field, 12 bits− 11 identifier bits− 1 retransmission bit

Control field, 6 bits− 4 data length code bits− 2 reserved bits

CRC field,15 bits

ACK field,2 bits

EOF field,7bits

Figure 2.11: Controller Area Network Data Frame (CAN 2.0A)

Example 2.3: We will use the process graph depicted in Figure 2.12, withthe processes mapped on two different nodes.The properties of the processescan be seen in Table 2.1. We make the assumption that the messagestransmitted by processes 1 and 2 will take 5 ms to transmit. The resultwhen we run the application is depicted in the Gantt chart in Figure 2.13.

2.3 The Controller Area Network 13

P1 P2

P4 P3

Node 1 Node 2

m1

m2

Figure 2.12: The application in Example 2.3 mapped on an architectureconsisting of 2 computational nodes

Table 2.1 Process parameters for Example 2.3Process Offset Exec.time (ms) Deadline Priority

1 0 10 20 0

2 0 5 80 2

3 0 10 35 1

4 0 5 20 2

10 20 30

Node 1

Node 2

0

Bus

Collision, P1 has higher priority

m1 m2

P2

P4P1

P3

Figure 2.13: Gantt chart for Example 2.3

Chapter 3

Design

This chapter will start off with an explanation on the background of ACCdesign. Then it will go on explaining the functionality of an ACC and thedesign chosen to fulfill it. Finally it will describe how the car, the road andthe other cars are modelled.

3.1 Background

Much work has been put into developing adaptive cruise control theory,both in academia and industry. Axehill and Sjoberg [2] and Bjorkdahl [3]have written master’s theses that cover the theoretical design of an ACC.The design for the ACC in this thesis is inspired by a patent by Jaguar,described by Bjorkdahl [3], however somewhat simplified.

3.2 ACC Functionality

Many cars and trucks of today are equipped with a cruise controller (CC).A CC is a comfort system that keeps the vehicle at a constant velocity, setby the driver. The conventional CC only has control over the engine, whichmeans that it cannot switch gears and it cannot break. This means that itis only used on roads where the velocity of the car is somewhat constant,for example on highways. The driver cannot relax too much though, sincethe CC does not care about vehicles in front. This is what the adaptivecruise controller (ACC) is trying to solve.

The ACC takes both a desired (maximum) velocity and a desired (min-imum) distance as input values from the driver. As long as no vehicle infront is closer than the desired distance, the ACC functions exactly as a CC.If a vehicle in front comes closer than the desired minimum distance theACC will adapt the velocity to follow the vehicle, as depicted in Figure 3.1.

15

16 Design

distact

distdesv vlead

Figure 3.1: ACC in action

3.3 System Overview

The ACC is constructed by extending a conventional CC, so we start bydescribing a CC. A standard CC is built as a feedback control loop, seeFigure 3.2. The CC is a control loop that measures the velocity, v, comparesit to the desired velocity, vdes, and then manipulates the throttle, T , suchthat the velocity eventually reaches the desired velocity.

CC CARv

v

vdes T

Figure 3.2: Cruise controller overview

This can now be seen as the inner loop. The adaptive functionality ofthe ACC will extend the CC by controlling the desired velocity, vdes, seeFigure 3.3. The outer loop can also be seen as a feedback control loop,with the goal of keeping the distance, dist, at least at the desired distance,distdes. As input variables it uses two values, the velocity, v, and thedistance, dist, and to control the distance it uses the desired velocity, vdes,as a control variable.

3.4 Logical Architecture

This section will discuss the logical architecture of the ACC, that is theequations desribing the functionality of the processes. The logical architec-ture will be divided into an inner and an outer loop.

3.4 Logical Architecture 17

CC CAR

+−

Leadingvehicle

Av

vdes

1s

v

dist

v

distdesT

vdes

Figure 3.3: Adaptive cruise controller overview

3.4.1 Inner Loop

The CC will be built as a proportional-integral controller (PI-controller).The reasons for choosing a PI-controller instead of a proportional-integral-derivative controller (PID-controller) are

• Easier to implement. Finding the derivative is not necessarily trivial.

• The derivative part of the controller has two functions, decreasingoverslope and increasing stability. In our application neither of theseare assumed to be a problem.

A PI-controller’s equation [8] is at the form

u(t) = Kpe(t) + Ki

∫ t

0

e(s)ds, (3.1)

where

• u(t) is the control signal that is sent to the plant,

• e(t) is the error between the desired and the actual output and

• Kp, Ki are the proportional and integral constants.

In our case the control signal, u(t), is the throttle, controlling how muchgas is given to the engine of the vehicle, which is the plant. The error, e(t),is the difference between the desired velocity and the actual velocity of thevehicle, ev(t) = vdes(t) − v(t). The constants Kp and Ki will be decided

18 Design

experimentally in Chapter 5. This gives us the controller equation for theinner loop:

T (t) = Kpev(t) + Ki

∫ t

0

ev(s)ds (3.2)

where T (t) is the function for the throttle.

3.4.2 Outer Loop

The outer loop will be slightly more complicated, since we have two issuesto consider, both the desired velocity and the desired distance. This resultsin three different scenarios, illustrated in Figure 3.4. The safety distance,distsafe, is the extra distance above the desired distance at which the ACCneed to start controlling. The reason that the ACC starts controlling be-fore the desired distance is actually reached, is because it takes time toslow down the vehicle. The value of the safety distance will be decided atimplementation.

• In the case when there is no vehicle closer than the desired distanceplus the safety distance it will feed the default desired velocity to theinner loop.

When a vehicle is detected within the desired distance plus the safetydistance, it must first be determined whether the velocity of the othervehicle is faster or slower than the desired velocity. This gives us twoscenarios:

• If it is faster, it can be ignored, since it will drive away from thevehicle being controlled.

• In the case that it is slower, the velocity must be controlled to ensurethat the desired distance is upheld. This is done by altering thedesired velocity that is sent to the inner loop. Ideally, we will convergeto the velocity of the vehicle in front just as we reach the distanceequaling the desired distance.

When the outer loop reaches the state where it needs to control thevehicle, it uses a PI-controller, just like the inner loop. In this case thecontrol signal, u(t), is the desired velocity, that is sent to the inner loop.The error, e(t), is the difference between the actual distance and the desireddistance, edist(t) = dist(t) − distdes(t). The constants Kp and Ki will bedecided experimentally in Chapter 5. This gives us the controller equationfor the outer loop:

vdes(t) = Kpedist(t) + Ki

∫ t

0

edist(s)ds (3.3)

3.5 Modelling the Environment 19

Vehicle in front closer than

Other caris faster

Other caris slower

No vehicle in front closer than distdes + distsafe

vref = vdes

vref = vdes vref = Kpe(t) + Ki

∫ t0 e(s)ds

distdes + distsafe

Figure 3.4: Different states of the outer loop

3.5 Modelling the Environment

Since we will run the ACC on a simulator instead of a real car, we mustmodel not only the ACC but also the vehicle itself, as well as the road weare driving on and other vehicles that will appear in front of ours. The firsttwo subsections will describe the model of the velocity sensor and the lastsubsection the model of the distance sensor.

3.5.1 Car Model

The property of the vehicle that we are interested in modelling is its velocityas a function of the throttle given to the engine. The description of thevehicle is a nonlinear differential equation [17]

v′(t) =Mw(t) + sign(v(t)) cAv2(t)ρ

2+ sign(v(t))rmCrr − rmg sinα(t)

mr(3.4)

where:

• Mw(t) [Nm] is the momentum on the wheels at time t

• c ≈ 0.3, is a dimensionless aerodynamic constant

• A ≈ 2.5 [m2], is the area of the front of the car

• ρ ≈ 1.2 [kg/m3], is the air density

• r ≈ 0.25 [m], is the wheel radius

• m ≈ 1200 [kg], is the mass of the car

• Crr ≈ 0.01 at asphalt, is a dimensionless rolling resistance coefficient

20 Design

• α(t) [rad] is the slope of the road at time t

• g ≈ 9.81 [m/s2], is the gravitational constant

and:

sign(v(t)) ={ −1 if v(t) ≥ 0

1 if v(t) ≤ 0

The momentum on the wheels is calculated by a linear transfer equationfrom the throttle, Mw = kT (t), where k is a constant. The value of k willbe decided experimentally in Chapter 5. The sign function in the nonlinearequation is due to the air and the rolling resistance changing from positiveforces to negative, as the velocity goes from positive to negative. Whenthe velocity is positive the air and the rolling resistance are negative forces,and when the velocity is negative they are positive forces.

3.5.2 Road

We will design a somewhat simplified road that does not have any turns.Weather conditions and other possibilities that alter the road’s propertieswill also be ignored. A road is modelled as a height function, f(p), of thevehicle’s position, see Figure 3.5.

0

height (h)

position (p)p0

f(p0)

p0 + 1

f(p)tangential of f(p0)

f ′(p0)

αp(p0)

Figure 3.5: Model of a road

To determine the slope at any given position p, we draw the tangentialto the function at point p, as illustrated in Figure 3.5. Moving one stepforward in the p direction, the tangential will, by definition, change heightby f ′(po). This gives us the right triangle in Figure 3.6, from which we canderive

tanαp(p0) = f ′(p0)

where αp is the slope as a function of the position. According to thedefinition of inverse function we now have:

3.5 Modelling the Environment 21

αp(p0) = arctan f ′(p0)

1

α(p0)

f ′(p0)

Figure 3.6: Right triangle derived from Figure 3.5

Now we have the value of the slope in any position. To calculate thevalue of the slope at a certain time, we need to first calculate the positionof the vehicle at that time, and then calculate the slope using the position.The position of the vehicle at time t, p(t), is equal to the integral of thevelocity from time 0 to time t,

∫ t

t0v(s)ds, which gives us:

α(t) = αp(p(t)) = αp

(∫ t

0

v(s)ds

)(3.5)

3.5.3 Other Cars

We model only one vehicle in front at a single time. That vehicle willbe modelled with a velocity and a starting distance from our vehicle. Itsposition, relative to our vehicle, will then be calculated using both vehicles’velocity, the starting distance and the time that has passed.

v vvlead vlead

Time t1Time 0

dist1dist0

Figure 3.7: Calculating the distance to the car in front

Assuming we know the starting distance, dist0, we can calculate thedistance at time t, dist(t), by the equation:

dist(t) = dist0 −∫ t1

0

(v(t) − vlead(t))dt (3.6)

Chapter 4

Implementation

This chapter will describe the implementation process. First, the task graphmodel of the ACC and its mapping will be described. Next, the car modelwill be implemented to enable testing of the ACC. Last, we will implementdisturbance processes that run on the same nodes as the ACC.

4.1 Modelling the ACC

This section will start by describing the logical architecture of the ACC,followed by the construction of a process graph describing its functionaldependencies. Finally, the processes will be mapped to computation nodesconstituting the execution platform.

4.1.1 Logical Architecture

The logical architecture started with an ACC implementation made byAkerholm et al. [1]. Due to our design having other requirements heavymodifications were made. Several of the elements were cut and the remain-ing processes have kept their names, but their functionalities have beenaltered. The end result is the logical architecture depicted in Figure 4.1.The functionality of the processes are:

objectRecognition calcDistOutput calcSpeedOutput

distSensor

speedSensor

throttleActuator

ACC

vdes

dist

distdes

vrel

v

vdes

throttle

Figure 4.1: Logical architecture of the ACC

23

24 Implementation

speedSensor: Measures the velocity of the vehicle and sends it to theACCInputs: -Outputs: Velocity

distSensor: Measures the distance to the closest vehicle in front and sendsit to the ACCInputs: -Outputs: Distance

objectRecognition: Calculates the relative speed to the vehicle in front.A positive value means that the other vehicle is faster, while a nega-tive value indicates a slower car in front.Inputs: Distance, VelocityOutputs: Relative velocity

calcDistOutput: Calculates the desired velocity according to the func-tionality described in Chapter 3Inputs: Distance, Velocity, Relative velocity, Desired distance, De-sired velocityOutputs: Desired velocity

calcSpeedOutput: Controls the velocity of the vehicle, indirectly, by chang-ing the throttleInputs: Velocity, Desired velocityOutputs: Throttle

throttleActuator: Controls the physical changing of the throttleInputs: ThrottleOutputs: -

The function calcSpeedOutput is handling the pure CC functionality.The adaptive part is handled by objectRecognition and calcDistOutput com-bined. We include the speed and distance sensor and the actuator for thethrottle as processes because we assume the data from the sensors have tobe processed, which takes time. Table 4.1 shows the timing properties ofthe processes. The total period of the system is 20 milliseconds. Thesevalues were taken from the design by Akerholm et al. [1].

4.1.2 Process Graph and Mapping to Nodes

The process graph is depicted in Figure 4.2. P1 and P2 are the velocity anddistance sensors respectively, P3 is objectRecognition, P4 is calcDistOutput,P5 is calcSpeedOutput, and P6 is throttleActuator.

Finally the processes are mapped to nodes, that are all connnected toa bus, see Figure 4.3.

4.2 Car Model 25

Table 4.1 Timing properties of the processesProcesses Timing properties

- BCET WCET

speedSensor 2 2

distSensor 2 2

objectRecognition 2 6

calcDistOutput 2 2

calcSpeedOutput 2 6

throttleActuator 2 2

P1 P2

P3

P4

P5

P6

Figure 4.2: Process graph of the ACC

4.2 Car Model

The car is designed using the nonlinear differential Equation (3.4) fromSection 3.5. This means there is no given way to solve the equation. Insteadwe resort to using a numerical method. To get a small truncation error,O(h4), we use the Runge-Kutta method [14]. The Runge-Kutta method isan iterative method. That means that there must be a starting point andlater values are gained by taking iterative steps. The smaller the step sizethe better the approximation. The method looks as follows:

k1 = hf(tn, vn),k2 = hf(tn + h

2, v − 2 + k1

2),

k3 = hf(tn + h2, vn + k2

2),

k4 = hf(tn + h, vn + k3),andvn+1 = vn + 1

6 (k1 + 2k2 + 2k3 + k4)

As the step, h, we have the period, 20 ms, at which the ACC functions.The old velocity is represented by vn and the new velocity by vn+1. tn is thetotal time passed. To get a better idea look at Figure 4.4, which depictsone iterative step. The function, f(t, y), is the nonlinear Equation (3.4)

26 Implementation

P3 P5 P6

P4

P2P1

Figure 4.3: The mapping of processes on the nodes.

earlier mentioned. The function has access to the actual throttle valueeven though it is not a direct input.

v (velocity)

t (time)

vn+1

vn

tn+1

h

tn

Figure 4.4: One step in the numerical solution

4.3 Approximations

Since we only have the value of the velocity in discrete points, according toSection 4.2, we must make approximations of the integrals from Chapter 3.

4.3.1 Inner Loop

Since we only have the value of e in discrete points, we must make anestimation of the integral

∫ t

0e(s)ds. We define the value of the error in a

discrete point, nh, as e(nh) = vdes(nh)− v(nh), where n is a non-negativeinteger and h is the period of the inner loop. To estimate the integral wewill now use the sum [6]:

4.3 Approximations 27

∫ t

0

ev(s)ds =∫ nh

0

ev(s)ds ≈n−1∑j=0

(h

2(ev(jh) + ev((j + 1)h)

)

Figure 4.5 gives a visual of how the sum estimates the integral. Astraight line is drawn between e(jh) and e((j + 1)h) and the estimation iseverything under that line.

(j + 1)h

e((j + 1)h)

e(jh)

jh

Figure 4.5: Estimation of integral with sum

4.3.2 Outer Loop

To estimate the integral∫ t

0e(s)ds, we use a sum. We define the value of the

error in a discrete point, nh, as edist(nh) = dist(nh)−distdes(nh), where nis a non-negative integer and h is the period of the outer loop. To estimatethe integral we will now use the sum [6]:

∫ t

0

edist(s)ds =∫ nh

0

edist(s)ds ≈n−1∑j=0

(h

2(edist(jh) + edist((j + 1)h))

)

4.3.3 Road

Since we only know the velocity of the vehicle in discrete points we use asum to estimate the value of the integral

∫ t

0v(s)ds. We define the value

of the velocity in a discrete point, nh, as v(nh), where n is a non-negativeinteger and h is the period at which the slope is updated. Then the estimateis:

∫ t

0

v(s)ds =∫ nh

0

v(s)ds ≈n−1∑j=0

(h

2(v(jh) + v((j + 1)h))

)

Now we have the complete calculation of α(t):

28 Implementation

α(t) = α(nh) = αp(p(nh)) = αp

(∫ nh

0

v(s)ds

)≈

αp

n−1∑j=0

(h

2(v(jh) + v((j + 1)h))

)

4.3.4 Other Cars

Since we only know the difference in velocity between our vehicle and thevehicle in front in discrete points we use a sum to estimate the value of theintegral

∫ t

0v(s) − vleadds. We define the value of the difference in velocity

in a discrete point, nh, as vdiff(nh) = (v(nh) − vlead(nh), where n is anon-negative integer and h is the period at which the velocity is updated.Then an estimate of the integral is:

∫ t

0

v(s) − vleadds =∫ nh

0

(v(s) − vlead(s))ds ≈

n−1∑j=0

(h

2(vdiff(jh) + vdiff((j + 1)h))

)

4.4 Background Processes

In a real car other processes coexist on the same nodes as the ACC pro-cesses. These other processes use both processor and bus resources. Tomake our simulation more realistic we will add dummy processes, that is,processes without functionality whose only purpose is to occupy processorand bus resources. We will add one dummy process on each of the nodesthat house ACC processes. Each dummy process will have the highestpriority on its respective node, and each of these processes will have anexecution time of one millisecond. The period will then be set to:

Period =1

Utilisation

where Utilisation is the percentage of processor capacity that the processwill occupy, divided by 100. We will also add two extra nodes, with oneprocess each, that are connected to the bus. The execution time of boththese processes is set to 0. One of these processes will send messages tothe other process over the bus, thus blocking the bus for the ACC. Thepriority of the messages transmitted by these processes will be higher thanthe priority of any message that is sent by the ACC, and each such message

4.4 Background Processes 29

will take 0.125 milliseconds to transmit. To vary the load on the bus, theperiods of the two processes is set to:

Period =0.125

BusUtilisationwhere BusUtilisation is the percentage of bus capacity that will be occu-pied, divided by 100.

See Figure 4.6 for the updated version of the hardware. P7 to P10 arethe processes introduced to use processor resources while P11 and P12 arethe processes designed to use bus resources.

P2 P3 P5 P6

P8 P9

P12

P1P4

P10

P11

Node1 Node2 Node3 Node4 Node5 Node6

P7

Figure 4.6: Final mapping of all processes on the nodes

Chapter 5

Experiments

In this chapter we will first describe how the experiments were setup andrun. After that we explain how the results were analyzed. Finally, theresults of experiments, and conclusions are presented.

5.1 Experiment Setup

Let us first study the ACC function. The inputs to the ACC are:

• Sim-time, simulation time in ms

• v0, starting velocity in km/h.

• vdes, desired velocity in km/h.

• dist0, starting distance in m.

• distdes, desired distance in m.

• Road, choosing a road.

• Vehicle, choosing a vehicle that driver in front of our vehicle.

• Backgroundi, a value [0,100], determining how many percent of back-ground processes there will be on node i, where i = 1, 2, 3, 4.

• Busload, a value [0,100], determining how many percent of the buswill be occupied by background messages.

The car’s velocity, the distance to the vehicle in front, and the desiredvelocity, will be written to separate files as an output of the simulation.There will be three other vehicles and four different roads to choose from.The choices of cars can be seen in Table 5.1 and the choice of roads can beseen in Table 5.2. Since the function of the fourth road may seem difficultto understand,

31

32 Experiments

-20

-15

-10

-5

0

5

10

15

20

0 500 1000 1500 2000 2500 3000

Hei

ght (

m)

Position (m)

5*sin(x/160)

Figure 5.1: Height function of road 4

Table 5.1 Other vehiclesOther vehicle # Velocity

1 70

2 110

3 ∞

In order to get results where only the CC functionality is used, vehiclenumber 3 is chosen.

The outputs to the output files will be in the form of pairs of outputand time. For example, the output file for the velocity will have pairs oftime and velocity, (velocity, time).

The communication between nodes will be done via a CAN bus thatcan transfer 100 kBytes/second. Messages handling is non-preemptive, thismeans that when a message has started to send it will finish even if there arehigher priority messages waiting to be sent. On the nodes preemptive fixedpriority scheduling (FPS) will be employed. The desired distance will be90 metres and the starting distance will be 150 metres in all experimentsinvolving adaptive cruise controller functionality. The proportional andintegral constants, Kp and Ki, are set to 1250 and 100 respectively for theinner loop, and 2 and 0.5 respectively for the outer loop. These valueswere chosen after manually testing the application. The maximum andminimum throttle values will be capped at ±15000, which correlates to avelocity of approximately ±240 km/h on a flat road. The throttle valuewas found by letting the cruise controller output a fixed throttle valueand controlling which velocity the vehicle reached. The throttle value isconsidered a dimensionless control variable that is converted to torque bythe vehicle model. To convert the throttle value to torque the vehiclemodel multiplies it by 0.032585, this value was found by manually testingthe application.

5.2 Performance Metric 33

Table 5.2 RoadsRoad # Slope

1 0

2 π36

3 − π36

4 arctan (cos ( position160

) · 5160

)

To get raw data to analyse we will run the ACC with many differentinput values. We will run the ACC with all possible combinations of thevalues found in Table 5.3. The result of each test is stored in a separatefile. In each test we simulate 2 minutes of system execution.

Table 5.3 Test valuesv0 vdes Road Vehicle

70 70 0 0

90 90 1 1

110 110 2 2

- 130 3 -

5.2 Performance Metric

To measure how well the functionality of the ACC is maintained underthe different scenarios the Quality-of-Control (QoC) performance criteriaIAE (Integral of the Absolute Error) [13] will be used. To measure theIAE, the velocity of the vehicle, and the distance to the vehicle in front,are compared to an idealised output. For the velocity, the smaller the totalabsolute difference between the velocity and the desired velocity, the higherthe quality is (see Figure 5.2). The equation to calculate the accumulateddifference, E(t), between time 0 and time t is:

E(t) =∫ t

0

|ev(t)|dt =∫ t

0

|vdes(s) − v(s)|ds (5.1)

Figure 5.2 shows a visual representation of how the QoC is calculated.Since we only have the velocity in discrete times, the integral will be

estimated using a sum. We define the value of the error in a discrete point,nh, as |ev(nh)| = |vdes(nh)− v(nh)|, where n is a non-negative integer andh is the period at which the ACC velocity is updated. Then the estimatelooks as this:

34 Experiments

Difference betweendesired and actual velocity

v velocity

t time

Desired velocity (vdes)

v

Figure 5.2: Quality-of-Control

E(t) =∫ t

0

|ev|(s)ds =∫ nh

0

|videal(s)−v(s)|ds ≈n−1∑j=0

∣∣∣∣h2 (e(jh) + e((j + 1)h))∣∣∣∣

The QoC for distance is calculated according to Algorithm 5.2, which isthe same way that the QoC for velocity is calculated, except the differencebetween the distance and the desired distance is only measured when theactual distance is smaller than the desired distance.

Algorithm 1 QoC algorithm for the ACC1: j=02: Sum = 03: while j<n do4: if distance((j + 1)h) < desired distance then5: Sum = Sum +

∣∣h2(e(jh) + e((j + 1)h))

∣∣6: end if7: j = j + 18: end while

The values we get might be large and hard to interpret. Therefore wemap the values into an interval [0,1], to make them easier to interpret andcompare. To normalize the values we divide them by the area of the smallestrectangle that completely encloses the function of e (see Figure 5.3). Whencalculating QoC values for the ACC, we add the QoC values for the velocityand the distance, and divide by the sum of the rectangles that enclose thetwo integrals.

This way we are guaranteed to get a value between 0 and 1, wherea smaller value indicates a better result. The normalization is obviouslynot very useful as long as we have only one graph, but it gets very usefulwhen comparing several scenarios. The upper value of the rectangle is

5.3 Results 35

Rectangle

e (error)

|vdes(t) − v(t)|

max|vdes(t) − v(t)|

t time

Figure 5.3: Normalizing Quality-of-Control

then chosen as the largest error among all the scenarios that are beingcompared, and all QoC values from the different scenarios are divided bythe same value. In our test cases we will have one normalizing value for eachgroup of tests that share the same inputs, except the background and busloads. This way we can study how the performance is changed as differentamounts of background load is added to the system.

5.3 Results

This section will go through the results of the experiments. Due to the vastnumber of experiments, a limited number of representative results will bepresented. The section will start by showing experiments with the CC andthe ACC where there is no extra background load on the nodes or on thebus. Then there will be experiments where there is background load on thenodes and on the bus to show how the performance is changed.

5.3.1 Cruise Controller

For the cruise controller we will show one example for each road. Thestarting velocity as well as the desired velocity will be 70 km/h in eachexample.

Example 5.1: For the first example we will use the straight road. Theresult can be seen in Figure 5.4. As was desired, the velocity starts andstabilizes at 70 km/h. It drops slightly in the beginning as the integral partof the controller is catching up.

Example 5.2: For the second example we will use the road that is uphillby five degrees.The result can be seen in Figure 5.5. This time the velocitydrops by almost 7 km/h in the beginning, which is not very good, but itstabilizes at the desired velocity reasonably fast.

36 Experiments

68.8

69

69.2

69.4

69.6

69.8

70

0 20 40 60 80 100 120

Vel

ocity

(km

/h)

Time (s)

Figure 5.4: CC with straight road

63

64

65

66

67

68

69

70

0 20 40 60 80 100 120

Vel

ocity

(km

/h)

Time (s)

Figure 5.5: CC with uphill road

Example 5.3: For the third example we will use the road that is downhillby five degrees. The result can be seen in Figure 5.6. This time the velocityincreases by almost 5 km/h in the beginning, which is not very good, butit stabilizes at the desired velocity reasonably fast.

Example 5.4: For the final example we will use the last road that goesboth uphill and downhill. The result can be seen in Figure 5.7. This timethe velocity never stabilizes since we are constantly switching between goinguphill and going downhill, but the velocity is staying within approximately1.5 km/h from the desired velocity, after the CC has kicked in.

5.3 Results 37

70

70.5

71

71.5

72

72.5

73

73.5

74

74.5

75

0 20 40 60 80 100 120

Vel

ocity

(km

/h)

Time (s)

Figure 5.6: CC with downhill road

66

67

68

69

70

71

72

0 20 40 60 80 100 120

Vel

ocity

(km

/h)

Time (s)

Figure 5.7: CC with rocky road

5.3.2 Adaptive Cruise Controller

For the adaptive cruise controller we will go through one example for eachroad. For the adaptive cruise controller we will show one example for eachroad. The starting velocity will be 90 km/h, the desired velocity will be110 km/h and the vehicle in front will be driving at 70 km/h in all examples.

Example 5.5: For the first example we will use the straight road. Theresult can be seen in Figure 5.8. As was desired, the velocity increasesat first. As the other vehicle comes within 120 metres of our vehicle, thevelocity decreases. Finally, the distance stabilizes at 90 metres, and ourvehicle’s speed stabilizes at the same velocity as the vehicle in front.

38 Experiments

60

70

80

90

100

110

120

130

140

150

0 20 40 60 80 100 120

Vel

ocity

(km

/h)/

Dis

tanc

e (m

)

Time (s)

velocitydistance

Figure 5.8: ACC with straight road

Example 5.6: For the second example we will use the uphill road. Theresult can be seen in Figure 5.9. As was desired, the velocity increasesat first. As the other vehicle comes within 120 metres of our vehicle, thevelocity decreases. Finally, the distance stabilizes at 90 metres, and ourvehicle’s speed stabilizes at the same velocity as the vehicle in front.

60

70

80

90

100

110

120

130

140

150

0 20 40 60 80 100 120

Vel

ocity

(km

/h)/

Dis

tanc

e (m

)

Time (s)

velocitydistance

Figure 5.9: ACC with uphill road

Example 5.7: For the third example we will use the downhill road. Theresult can be seen in Figure 5.10. As was desired, the velocity increasesat first. As the other vehicle comes within 120 metres of our vehicle, thevelocity decreases. Finally, the distance stabilizes at 90 metres, and ourvehicle’s speed stabilizes at the same velocity as the vehicle in front.

5.3 Results 39

60

70

80

90

100

110

120

130

140

150

0 20 40 60 80 100 120

Vel

ocity

(km

/h)/

Dis

tanc

e (m

)

Time (s)

velocitydistance

Figure 5.10: ACC with downhill road

Example 5.8: For the final example we will use the last, rocky, road. Theresult can be seen in Figure 5.11. As was desired, the velocity increasesat first. As the other vehicle comes within 120 metres of our vehicle, thevelocity decreases. Finally, the distance stabilizes at approximately 90 me-tres, and our vehicle’s speed stabilizes at approximately the same velocityas the vehicle in front.

60

70

80

90

100

110

120

130

140

150

0 20 40 60 80 100 120

Vel

ocity

(km

/h)/

Dis

tanc

e (m

)

Time (s)

velocitydistance

Figure 5.11: ACC with rocky road

5.3.3 Background Load on the CC

For these examples we will test the functionality of the CC as extra loadis placed on the nodes and on the bus. For each experiment we will use

40 Experiments

different levels of background load on the nodes and on the bus. Thestarting velocity as well as the desired velocity will be 70 km/h in eachexample, just as in the previous examples. We will use road number 4, therocky road.

Example 5.9: In Figure 5.12 there is 75 % extra load on the nodes. Evi-dently the functionality of the CC has not deteriorated.

66

67

68

69

70

71

72

0 20 40 60 80 100 120

Vel

ocity

(km

/h)

Time (s)

Figure 5.12: CC with 75 % extra load on the nodes

Example 5.10: Figure 5.13 shows the result with 78 % extra load on thenodes. Initially the CC functions correctly, but after approximately 60seconds, the velocity starts fluctuating violently.

20

30

40

50

60

70

80

90

100

110

120

0 20 40 60 80 100 120

Vel

ocity

(km

/h)

Time (s)

Figure 5.13: CC with 78 % extra load on the nodes

5.3 Results 41

Example 5.11: If we increase the load on the nodes another percent, to79 %, we get the result shown in Figure 5.14. Now the velocity startsfluctuating immediately.

-200

-150

-100

-50

0

50

100

150

200

250

0 20 40 60 80 100 120

Vel

ocity

(km

/h)

Time (s)

Figure 5.14: CC with 79 % extra load on the nodes

Example 5.12: As we increase the load even more we get different, butstill erroneous, functionality as can be seen in Figure 5.15, where there is85 % extra load on the nodes.

-300

-200

-100

0

100

200

300

0 20 40 60 80 100 120

Vel

ocity

(km

/h)

Time (s)

Figure 5.15: CC with 85 % extra load on the nodes

Example 5.13: As we reach extra load equal to or higher than 90 %, weget the result depicted in Figure 5.16. At this point the processes of theCC are completely blocked from running and no throttle is given to theengine.

42 Experiments

-100

-80

-60

-40

-20

0

20

40

60

80

0 20 40 60 80 100 120

Vel

ocity

(km

/h)

Time (s)

Figure 5.16: CC with 90 % extra load on the nodes

Example 5.14: Now we will study the performance when we add extraload on the bus. When we add 90 % extra load on the bus we get theresult depicted in Figure 5.17. Evidently the functionality of the CC hasnot deteriorated.

66

67

68

69

70

71

72

0 20 40 60 80 100 120

Vel

ocity

(km

/h)

Time (s)

Figure 5.17: CC with 90 % extra load on the bus

Example 5.15: If we increase the load on the bus to 99 %, we get theresult shown in Figure 5.18. Evidently the load on the bus has no effect onthe functionality of the CC even when it is set this high.

Table 5.4 and Table 5.5 shows the QoC values for these experiments.As expected, the QoC value rises greatly as the background load on the

5.3 Results 43

66

67

68

69

70

71

72

0 20 40 60 80 100 120

Vel

ocity

(km

/h)

Time (s)

Figure 5.18: CC with 99 % extra load on the bus

nodes increases, but stays almost the same when the background load onthe bus increases.

Table 5.4 QoC values for CC with background load on the nodesExtra load on nodes (%) QoC values (%)

75 0.0037

78 0.0449

79 0.1841

85 0.5150

90 0.2407

Table 5.5 QoC values for ACC with background load on the busExtra load on bus (%) QoC values (%)

90 0.0036

99 0.0037

5.3.4 Background Load on the ACC

For these examples we will test the functionality of the ACC as extra loadis placed on the nodes and on the bus. For each experiment we will usedifferent levels of background load on the nodes and on the bus. Thestarting velocity will be 90 km/h, the desired velocity will be 110 km/hand the vehicle in front will be driving at 70 km/h. We will use roadnumber 1, the flat road.

44 Experiments

Example 5.16: In Figure 5.19 there is 75 % extra load on the nodes.Evidently the functionality of the ACC has not deteriorated.

60

70

80

90

100

110

120

130

140

150

0 20 40 60 80 100 120

Vel

ocity

(km

/h)/

Dis

tanc

e (m

)

Time (s)

velocitydistance

Figure 5.19: ACC with 75 % extra load on the nodes

Example 5.17: Figure 5.20 shows the result with 78 % extra load on thenodes. Initially the CC functions correctly, but after less than 20 seconds,the velocity starts fluctuating violently.

0

20

40

60

80

100

120

140

160

0 20 40 60 80 100 120

Vel

ocity

(km

/h)/

Dis

tanc

e (m

)

Time (s)

velocitydistance

Figure 5.20: ACC with 78 % extra load on the nodes

Example 5.18: If we increase the load on the nodes another percent, to79 %, we get the result shown in Figure 5.21. Now the velocity startsfluctuating almost immediately.

5.3 Results 45

-250

-200

-150

-100

-50

0

50

100

150

200

250

0 20 40 60 80 100 120

Vel

ocity

(km

/h)/

Dis

tanc

e (m

)

Time (s)

velocitydistance

Figure 5.21: ACC with 79 % extra load on the nodes

Example 5.19: As we increase the load even more we get different, butstill erroneous, functionality as can be seen in Figure 5.22, where there is85 % extra load on the nodes.

-2000

-1500

-1000

-500

0

500

1000

0 20 40 60 80 100 120

Vel

ocity

(km

/h)/

Dis

tanc

e (m

)

Time (s)

velocitydistance

Figure 5.22: ACC with 85 % extra load on the nodes

Example 5.20: As we reach extra load equal to or higher than 90 %, weget the result depicted in Figure 5.23. At this point the processes of theACC are completely blocked from running and no throttle is given to theengine.

Example 5.21: Now we will study the performance when we add extraload on the bus. When we add 90 % extra load on the bus we get the result

46 Experiments

0

500

1000

1500

2000

2500

0 20 40 60 80 100 120

Vel

ocity

(km

/h)/

Dis

tanc

e (m

)

Time (s)

velocitydistance

Figure 5.23: ACC with 90 % extra load on the nodes

depicted in Figure 5.24. Evidently the functionality of the ACC has notdeteriorated.

60

70

80

90

100

110

120

130

140

150

0 20 40 60 80 100 120

Vel

ocity

(km

/h)/

Dis

tanc

e (m

)

Time (s)

velocitydistance

Figure 5.24: ACC with 90 % extra load on the bus

Example 5.22: If we increase the load on the bus to 99 %, we get theresult shown in Figure 5.25. Evidently the load on the bus has no effect onthe functionality of the ACC even when it is set this high.

Table 5.6 and Table 5.7 shows the QoC values for this experiment. Asexpected, the QoC value rises greatly as the background load on the nodesincreases, but stays almost the same when the background load on the busincreases. The reason why the QoC value is so low when the background

5.4 Discussion 47

60

70

80

90

100

110

120

130

140

150

0 20 40 60 80 100 120

Vel

ocity

(km

/h)/

Dis

tanc

e (m

)

Time (s)

velocitydistance

Figure 5.25: ACC with 99 % extra load on the bus

load on the nodes is 90 % is because the QoC for the distance does not careif the distance is greater than the desired distance.

Table 5.6 QoC values for ACC with background load on the nodesExtra load on nodes (%) QoC values (%)

75 0.0009

78 0.0009

79 0.0386

85 0.3631

90 0.0390

Table 5.7 QoC values for ACC with background load on the busExtra load on bus (%) QoC values (%)

90 0.0008

99 0.0008

5.4 Discussion

One conclusion that can be drawn by looking at some of the pictures, forexample Figure 5.20, is that the velocity fluctuates much faster than whatappears realistic. This is because, while we have set an upper bound onthe throttle values, we have not set an upper bound for the acceleration. Ifwe want more realistic results we need to set an upper bound for the accel-eration, either in the ACC or in the car model. Still, even while somewhat

48 Experiments

unrealistic, the results of the simulations still gives a good estimation ofwhen the functionality of the ACC is changed by the extra load. Anotherobservation is that the velocity drops or increases slightly at the start ofsome experiments. This is because the controller needs some time to ad-just. In a real vehicle we would have an initial throttle value and would beable to avoid this.

If we look at the mean values of the QoC values when sorting basedon the background load on the nodes and the background load on the buswe find the results depicted in Figure 5.26, Figure 5.27, Figure 5.28 andFigure 5.29. The figures are based on the values of all experiments, notonly the ones presented in the thesis. Some extra values for the backgroundload on the nodes are also added.

The conclusion that we can draw from the results is that the function-ality of the ACC is unchanged until there is a high amount of backgroundload on the nodes. When the background load gets too high, the ACC isno longer able to control the velocity properly. As the background loadreaches 90 % the ACC completely shuts down.

The extra load on the bus has a very small effect on the functionality ofthe ACC. The reason for this is probably that the bus is non-preemptive,which means that the messages sent by the ACC will not be completelyblocked out. Of course, if the background load on the bus was modelleddifferently, the results might have been different.

0

0.2

0.4

0.6

0.8

1

70 75 80 85 90 95

Mea

n of

QoC

Background load on nodes

Figure 5.26: Cruise controller QoC values for different background loadson nodes

5.4 Discussion 49

0

0.002

0.004

0.006

0.008

0.01

86 88 90 92 94 96 98 100

Mea

n of

QoC

Background bus load

Figure 5.27: Cruise controller QoC values for different background loadon the bus

0

0.1

0.2

0.3

0.4

0.5

70 75 80 85 90 95

Mea

n of

QoC

Background load on nodes

Figure 5.28: Adaptive cruise controller QoC values for different back-ground loads on nodes

50 Experiments

0

0.001

0.002

0.003

0.004

0.005

86 88 90 92 94 96 98 100

Mea

n of

QoC

Background bus load

Figure 5.29: Adaptive cruise controller QoC values for different back-ground load on the bus

Chapter 6

Conclusions and FutureWork

In this chapter we will summarize the contributions of this thesis, and alsopoint out some directions for future research.

6.1 Conclusions

In this thesis we have implemented and simulated a distributed version ofan adaptive cruise controller. We have based the controller and the vehicleon previously designed models.

As discussed in Section 1.3 the goal of this thesis has been to designand implement an adaptive cruise controller, as a distributed system, runit on a simulator and test its performance under different scenarios. InChapter 3 we have designed an adaptive cruise controller based on a modelby Jaguar. This model is based on separating the controlling of the velocityand the distance into an inner and an outer loop. Chapter 3 also containsthe design of the environment. In Chapter 4 we have implemented thedesign from Chapter 3.

The experimental results, from Chapter 5, show us that the adaptivecruise controller functionality is upheld until 78, or more, percent back-ground load are added to the nodes. At that point the performance startsdeteriorating, until it finally shuts down completely as the background loadon the nodes reaches 90 percent. The background load on the bus doesnot have an effect on the functionality, probably because the bus is non-preemptive.

6.2 Future Work

In this thesis we have only implemented an adaptive cruise controller andtested it with dummy processes putting extra load on the nodes and on

51

52 Conclusions and Future Work

the bus. As future work more functions could be implemented and runalongside the adaptive cruise controller. The ideal thing would be to getan entire actual system from a car manufacturer and simulate. A slightlyless ambitious idea would be to implement a bound on the acceleration,either in the ACC or in the car model.

Another course could be to implement a better way of interpreting theresults gained from simulating. Then one could possibly use the interpre-tation of these results as an aid to optimize mapping by comparing thesimulation results produced with different mappings.

Bibliography

[1] Akerholm, M., Moller, A., Hansson, H., and Nolin, M. To-wards a dependable component technology for embedded system appli-cations. In Proceedings of the 10th IEEE Workshop on Object-OrientedReal-Time Dependable Systems (2005), pp. 320–328.

[2] Axehill, D., and Sjoberg, J. Adaptive cruise control for heavyvehicles. Master’s thesis, Linkoping University, 2003.

[3] Bjorkdahl, D. Control principle for adaptive cruise control. Master’sthesis, Uppsala University School of Engineering, 2002.

[4] Bosch. CAN Specification, version 2.0 ed. Postfach 50, D-700Stuttgart 1, 1991.

[5] Eberle, S., Ebner, C., Elmenreich, W., Farber, G., Gohner,

P., Haidinger, W., Holzmann, M., Huber, R., Schlatterbeck,

R., Kopetz, H., and Stothert, A. Specification of the TTP/A pro-tocol. Research Report 61/2001, Technische Universitat Wien, Institutfur Technische Informatik, Treitlstr. 1-3/182-1, 1040 Vienna, Austria,2001.

[6] Elden, L., and Wittmeyer-Koch, L. Numeriska berakningar.Studentlitteratur, 2001.

[7] Fredriksson, L.-B. Can for critical embedded automotive networks.IEEE Micro 22, 4 (2002), 28–35.

[8] Glad, T., and Ljung, L. Reglerteknik. Grundlaggande teori. Stu-dentlitteratur, 1989.

[9] Johansson, K. H., Torngren, M., and Nielsen, L. Vehicle ap-plications of controller area network. In Handbook of Networked andEmbedded Control Systems, D. Hristu-Varsakelis and W. S. Levine,Eds. Birkhauser, 2005, pp. 741–766.

[10] Kopetz, H. REAL-TIME SYSTEMS: Design Principles for Dis-tributed Embedded Applications. Kluwer Academic Publishers, 1997.

53

54 Bibliography

[11] Liu, C., and Layland, J. W. Scheduling algorithms for multipro-gramming in a hard-real-time environment. J. ACM 20, 1 (1973),46–61.

[12] Maki-Turja, J. Engineering Strength Response-Time Analysis — ATiming Analysis Approach for the Development of Real-Time Systems.PhD thesis, May 2005.

[13] Marti, P., Fuertes, J., Fohler, G., and Ramamritham, K.

Improving quality-of-control using flexible timing tonstraints: Metricand scheduling issues. In Real-Time Systems Symposium, 23rd IEEE(2002), pp. 91–100.

[14] Nordling, C., and Osterman, J. Physics Handbook for Scienceand Engineering. Studentlitteratur, 1999.

[15] Pop, P., Eles, P., and Peng, Z. Analysis and Synthesis of Dis-tributed Real-Time Embedded Systems. Kluwer Academic Publishers,2004.

[16] Wolf, W. Computers as Components: Principles of Embedded Com-puting System Design. CA: Morgan Kaufman, 1997.

[17] Wong, J. Theory of Ground Vehicles. John Wiley and Sons Inc.,1978.

Upphovsratt

Svenska

Detta dokument halls tillgangligt pa Internet - eller dess framtida ersattare - underen langre tid fran publiceringsdatum under forutsattning att inga extra-ordinara om-standigheter uppstar.

Tillgang till dokumentet innebar tillstand for var och en att lasa, ladda ner, skrivaut enstaka kopior for enskilt bruk och att anvanda det oforandrat for ickekommersiellforskning och for undervisning. Overforing av upphovsratten vid en senare tidpunkt kaninte upphava detta tillstand. All annan anvandning av dokumentet kraver upphovsman-nens medgivande. For att garantera aktheten, sakerheten och tillgangligheten finns detlosningar av teknisk och administrativ art.

Upphovsmannens ideella ratt innefattar ratt att bli namnd som upphovsman i denomfattning som god sed kraver vid anvandning av dokumentet pa ovan beskrivna sattsamt skydd mot att dokumentet andras eller presenteras i sadan form eller i sadantsammanhang som ar krankande for upphovsmannens litterara eller konstnarliga anseendeeller egenart. For ytterligare information om Linkoping University Electronic Press seforlagets hemsida http://www.ep.liu.se/.

Copyright

EnglishThe publishers will keep this document online on the Internet - or its possible replace-ment - for a considerable time from the date of publication barring exceptional circum-stances.

The online availability of the document implies a permanent permission for anyone toread, to download, to print out single copies for your own use and to use it unchanged forany non-commercial research and educational purpose. Subsequent transfers of copyrightcannot revoke this permission. All other uses of the document are conditional on theconsent of the copyright owner. The publisher has taken technical and administrativemeasures to assure authenticity, security and accessibility.

According to intellectual property law the author has the right to be mentioned whenhis/her work is accessed as described above and to be protected against infringement.For additional information about the Linkoping University Electronic Press and itsprocedures for publication and for assurance of document integrity, please refer to itsWWW home page: http://www.ep.liu.se/.

c© Pontus RiisLinkoping, 2007

Avdelning, InstitutionDivision, Department

DatumDate

Sprak

Language

� Svenska/Swedish

� Engelska/English

�

RapporttypReport category

� Licentiatavhandling

� Examensarbete

� C-uppsats

� D-uppsats

� Ovrig rapport

�URL for elektronisk version

ISBN

ISRN

Serietitel och serienummerTitle of series, numbering

ISSN

Titel

Title

ForfattareAuthor

SammanfattningAbstract

NyckelordKeywords

Much functionality of today’s vehicles runs as software on embeddedcomputer systems. This includes, for example, automatic climate con-trol and engine control. As the processors necessarily are located indiffent physical locations inside the vehicle wires must be drawn be-tween processors that need to communicate. Therefore, it is typicalto have one or several buses connecting the processors in an embed-ded computer network, thus creating a distributed system. As someparts of the system in the car have real-time properties, it is necessaryto validate that the real-time properties are upheld in the distributedsystem.

This thesis presents the design and implementation of an adaptivecruise controller (ACC), which is a cruise controller that also keeps aminimum distance to the closest vehicle in front. Further, the perfor-mance of the ACC has been evaluated using an existing system-levelsimulator for distributed real-time systems together with metrics forQuality-of-Control (QoC).

The ACC has then been simulated under different scenarios. Thescenarios include outside conditions, for example the slope of the road,the behaviour of the vehicle in front, and the desired velocity, as wellas internal conditions as adding different amounts of extra load on theprocessors and the bus.

The results show that the functionality of the ACC starts deteriorat-ing when the extra load on the nodes reaches high levels. When theextra load reaches very high levels, the ACC stops functioning com-pletely. The results also show that the extra load on the bus has verylittle effect on the performance of the ACC.

IDA,Dept. of Computer and Information Science581 83 Linkoping

13th June 2007

—

LITH-IDA/DS-EX–07/007–SE

—

urn:nbn:se:liu:diva-9357

Simulation of a Distributed Implementation of an Adaptive Cruise Con-troller

Pontus Riis

××

Adaptive Cruise Controller, Simulation, Embedded Real-Time Dis-tributed System