IN DEGREE PROJECT COMPUTER SCIENCE AND ENGINEERING,SECOND CYCLE, 30 CREDITS

, STOCKHOLM SWEDEN 2019

Quantitative Requirements Testing for Autonomous Systems-of-Systems: Case Studies in Platooning

FABIAN STRÖM

KTH ROYAL INSTITUTE OF TECHNOLOGYSCHOOL OF ELECTRICAL ENGINEERING AND COMPUTER SCIENCE

Quantitative Requirements Testing for

Autonomous Systems-of-Systems: Case Studies in

Platooning

Masters Thesis in Computer Science

Fabian Stromfabstr@kth.se

Examiner: Joakim Gustafsson

Supervisor: Karl Meinke

February 26, 2019

Abstract

A platoon, or a road train, has many different benefits such as safety, fuelefficiency and road utilisation. However it must also be safe to use and must thusbe thoroughly tested. This report looks at the specific use case of emergencybraking using three different emergency braking strategies and two models ofcommunication. A cooperative emergency braking strategy, a naive emergencybraking strategy and the combination of both are tested. It is found that thecombination of both performs the best.

Sammanfattning

En platoon, eller ett vagtag, har manga fordelar sasom bransleeffektivitetoch vagutnyttjande. Daremot maste den ocksa vara saker att anvanda ochdarfor grundligt testad. Denna rapport beaktar det specifika anvandarfalletnodbromsning genom tre olika nodbromsstrategier och tva modeller for kom-munikation. En samarbetande nodbromsstrategi, en naiv nodbromsstrategi ochkombinationen av de tva testas. Resultatet ar att kombinationen av de tvapresterar bast.

Contents

1 Introduction 31.1 Hypothesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.2 Structure of the report . . . . . . . . . . . . . . . . . . . . . . . . 41.3 Sustainable development . . . . . . . . . . . . . . . . . . . . . . . 41.4 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Background 52.1 Platooning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.3 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3.1 Random testing . . . . . . . . . . . . . . . . . . . . . . . . 82.3.2 Learning based testing . . . . . . . . . . . . . . . . . . . . 82.3.3 Propositional linear temporal logic . . . . . . . . . . . . . 8

2.4 Analysis of platooning systems . . . . . . . . . . . . . . . . . . . 10

3 The platooning simulator 113.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.2 The Vehicle Communication Model . . . . . . . . . . . . . . . . . 13

3.2.1 The radio channel . . . . . . . . . . . . . . . . . . . . . . 133.2.2 The multiple access scheme . . . . . . . . . . . . . . . . . 153.2.3 The communication model . . . . . . . . . . . . . . . . . 153.2.4 The transmission algorithm . . . . . . . . . . . . . . . . . 163.2.5 Estimating an upper bound for the timeout values in CEBP 17

3.3 Packet loss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.4 Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.5 The emergency braking strategies . . . . . . . . . . . . . . . . . . 19

3.5.1 The cooperative emergency braking protocol . . . . . . . 203.5.2 CACC emergency brake . . . . . . . . . . . . . . . . . . . 223.5.3 CEBP and CACC emergency brake combined . . . . . . . 22

4 Methods 234.1 The binary search method . . . . . . . . . . . . . . . . . . . . . . 234.2 The random testing tool . . . . . . . . . . . . . . . . . . . . . . . 244.3 The visualization tool . . . . . . . . . . . . . . . . . . . . . . . . 26

1

5 Testing results 295.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295.2 Test results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

6 Discussion and conclusions 376.1 Evaluation of the testing method . . . . . . . . . . . . . . . . . . 376.2 Discussion of the results . . . . . . . . . . . . . . . . . . . . . . . 38

6.2.1 Validity of results . . . . . . . . . . . . . . . . . . . . . . . 386.3 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Bibliography 41

2

Chapter 1

Introduction

We live in a world where more and more systems are becoming digitalized andcomputer systems are becoming integral to many things in everyday life. Thesesystems can have high degrees of complexity and more often than not morethan a single manufacturer is involved in creating a finished product. Of coursethis product needs to be tested to ensure safe operation, a difficult task sincedetails of one part of the system or source code is most likely not available foranother manufacturer. Intellectual property rights and the natural secrecy ofmanufacturing companies make the task of software and hardware testing evenmore difficult; each part of a system is a system itself, rendering the product asystem of systems.

This report describes a method for testing such a system of systems forthe problem of platooning. In contrast to self driving cars, another emergingproduct, a platoon is composed of several vehicles that together form a unit onthe motorway by driving close to each other to form a “road train”, with thegoal of decreasing fuel consumption by decreasing the drag formed by the air.

A platoon is a good example of a system of systems: Each truck may bemanufactured by different manufacturers and each truck is composed of a numberof subsystems each interacting with each other.

Platoons are studied with respect to qualitative safety were high level logicalstatements are used to find safe platoons. Furthermore quantitative safety isdiscussed by using sensitivity analysis and parameter tuning to find the optimalsafe configuration of any found safe platoon.

A case study is performed on coordinated emergency braking of a platoon bycomparing three methods for performing the braking, a distributed cooperativeprotocol, a naive emergency braking and a combination of both. The goal is todetermine the minimum constant time gap between the vehicles where there areno inter-vehicle crashes. A Monte Carlo algorithm is constructed to evaluatevarious platoon configurations.

3

1.1 Hypothesis

The hypothesis for this report is that a binary search method (also known asthe interval halving method) can be used with automated testing to find theminimal safe constant inter-vehicle time gap.

1.2 Structure of the report

The structure of this report is as follows: The theoretical background is given inChapter 2 with the simulator and communication scheme used for the testingis detailed in Chapter 3. The methods used to evaluate the platoon is given inChapter 4 whilst the test results are presented in Chapter 5. Finally conclusionsare made and discussed in Chapter 6.

1.3 Sustainable development

Economical, social and ecological aspects of sustainable development is notapplicable to this report as it is about a theoretical subject (testing of a system)within a theoretical field (computer science). It could be argued that platooningitself is subject to the aspects above but this report uses platooning a case study.

1.4 Acknowledgments

Many thanks to Karl Meinke for supervising this thesis project and to CarlBergenhem for his extensive knowledge of the area and many interesting andinformative discussions.

The research leading to these results has been performed in the SafeCOPproject, that received funding from the ECSEL Joint Undertaking under grantagreement 692529, and from Vinnova Swedish national funding.

4

Chapter 2

Background

This chapter provides a background to the work described in this report: firstplatooning overall is described followed by an overview to the radio schemesapplicable to platooning. Finally methods for testing are described and differentways of a analyzing a platooning system.

2.1 Platooning

A platoon, also called a road train, can be described as a number of vehiclestravelling together with short inter-vehicle gaps [22] and can be seen as acooperative cyber-physical system of systems (Co-CPS) [2]. Figure 2.1 shows asimple 1-dimensional platoon with 3 vehicles with the inter-vehicle gap marked.

Figure 2.1: A 1-dimensional platoon with three vehicles, V0, V1 and V2.

In the past decades there have been several projects related to platooning (theconcept of having vehicles travelling in a platoon) such as SARTRE, PATH,GCDC, Energy ITS and SCANIA Platooning [3]. All these projects, whilsthaving a similar goal of enabling vehicle platooning, have different demands onthe roads and infrastructure, ranging from none to dedicated platooning lanesequipped with markers.

Platooning is beneficial for the safety, fuel efficiency and road utilization intraffic:

The safety is increased as a fully automatic braking decreases the reactiontime compared to a human since the system can react faster and no human needsto press a braking pedal or some emergency braking button [18]. For example,in a simulation the reaction time for a human to press a button to enact an

5

emergency braking mode of a platoon vehicle has been measured to 0.5 to 0.6 s[21]. This is a long time for a computer.

Fuel efficiency is improved as air drag is reduced when the inter-vehicle gapsare reduced [16]. Within the Energy ITS project a platoon of 3 vehicles travellingat 80 km/h with a inter-vehicle gap of 10 m measured fuel savings at 14 % forthe platoon [23]. Moreover, carbon dioxide emissions can be reduced [18], forexample the Energy ITS platoon measured savings of 2.1 % in a macroscopicview with 40 % usage of platoons for heavy vehicles [23].

Finally, the number of vehicles on the road can be increased by reducing theinter-vehicle gap making the road utilization more efficient [18].

For a road travelling vehicle there are two forms of control: longitudinalcontrol can be described as forward/backward on the road whilst lateral controlenables lane switching and turns.

In a platooning system the longitudinal control is used to control the distanceto the vehicle in front [20]. To keep the safety benefits of platooning thelongitudinal control needs to control the braking and emergency braking. It canbe noted that the platoon shall not brake harder than what the braking vehiclewith the most limited braking capabilities can manage [16]. If this were to bedone, the vehicle behind the most limited vehicle would crash into the mostlimited vehicle.

However, a platoon unable to take turns or switch lanes would be ratherlimited and so for a fully automated platoon lateral control is also needed. Forexample SCANIA and GCDC platoons have manual lateral control [3].

2.2 Communication

Wireless communication for V2x (which stands for Vehicle to vehicle and Vehicleto infrastructure) in the European Union is defined in the European StandardETSI ITS G5 (European Telecommunications Standards Institute IntelligentTransport Systems) which is based on IEEE 802.11-20121 [11].

For wireless communication the 802.11 standard describes the 802.11p physicallayer for V2x communication [20], 802.11p uses a Carrier Sense Multiple Accessscheme with Collision Avoidance (CSMA/CA) [6].

To avoid collisions on the radio channel the sender listens to the channelfor some predetermined period and if the channel is free the transmission isperformed. If the channel is not free the sender randomly selects a period towait before performing the transmission. However it only counts down when thechannel is free [5].

ETSI ITS G5 defines two message types that are of interest:

• Cooperative Awareness Messages (CAMs) are periodically sent messagescontaining status information for vehicles. The frequency of the transmis-sions is variable and defined to be 1 to 10 Hz [9].

1IEEE 802.11-2012 has been superseeded in a later revision, IEEE 802.11-2016.

6

• Decentralized Environmental Notification Messages (DENMs) are triggeredby an event [10].

Frequent status updates can make platooning a bandwidth demanding appli-cation: Each CAM has a size of 400 to 500 bytes [20] and ETSI ITS G5 identifiesfour channels to use where each channel has a theoretical maximum bandwidthof 27 Mbit/s [20]. With e.g. a platoon of 7 vehicles and status messages every 10ms the bandwidth needs to be 2.8 Mbit/s for each platoon. Furthermore, there isa back off between messages during collision avoidance, making 802.11 unreliable[6]. Thus it has been proposed in [7] to preschedule the communication withina platoon and use a dedicated channel for the communication. This can e.g.be done with a time divided access scheme (TDMA) [7] where only a specificvehicle is allowed to transmit at any specific time.

2.3 Testing

Software testing can be divided into two areas, white-box testing and black-boxtesting. With white-box testing the tester has knowledge of the internal structureof the system under test. With black-box testing the tester only have access toexternal descriptions of the system under test [17]. White-box testing will notbe discussed further.

Conceptually black-box testing can be viewed as regarding the system undertest as a “black box” where the inputs is processed by some unknown functionor procedure which yields the outputs.

Some basic terms needed to define testing are:

• System under test – The system under test is self explanatory.

• Oracle – The oracle problem in software testing is the problem of deter-mining whether a test case was successful or not. The oracle determinesthis since it by some means having knowledge of the correct answer [17].

• Test case – Each set of input to and outputs from the system under testforms a test case, together with pre- and postfix values [17].

• Test requirement ”A test requirement is a specific element of a softwareartifact that a test case must satisfy or cover.” [17]

• Requirements testing – Testing the system with respect to high levelrequirements described for it (an example is testing a platoon against“vehicles in a platoon must never collide with each other”).

Testing can be done at different levels with different techniques and goals foreach level. Three main levels are unit testing, integration testing and systemtesting [17].

With unit testing a function or some other part of the system is tested withregard to its implementation. Integration testing tests how different parts of thesystem under test works together and finally system testing ensures that thesystem works with respect to its architectural design [17].

7

2.3.1 Random testing

The idea of random testing is to generate random inputs to the system undertest and then having an oracle evaluating the result [13]. Random testing is notmuch worse than systematic testing methods and can be a cheap way of findingerrors [8]. However, an oracle is not always easily available (or is very hard todefine) and it is hard to estimate the test coverage from the generated test cases[13].

The probability of finding an error can be high,

P (at least on error found) = 1− (1−Θ)n

where Θ is the failure rate of the system under text [8], with the negation ofwhich being

P (no errors found) = (1−Θ)n

For a particular use case of platooning emergency braking, the success of a testcase could be determined by an oracle such as “the test case fails if and only ifthere exists a distance ≤ 0 between any two vehicles”.

However, with random testing it is hard to reason about how much that isactually tested.

2.3.2 Learning based testing

Learning based testing is a black box testing paradigm for automated require-ments testing. The testing tool uses machine learning techniques to learn amodel representing a system which is model checked against some system re-quirements written in PLTL (Propositional Linear Time Logic, described below)[15]. Compared with random testing, an estimate of how much of the systemthat is actually learned can be computed.

Learning based testing is divided into two phases, first the system under testis learned until a certain number of hypothesis automata has been learned or afixed amount of time has passed. During the second phase the final hypothesisautomata is verified using a model checker. The quality of the model checkerresult can be determined by estimating how well the system was learned which isdone using a stochastic equivalence checker: Out of a certain number of randomtest cases, how often does the test result differ between the actual system andthe learned model [14]. A architecture of the tool is shown in Figure 2.2.

2.3.3 Propositional linear temporal logic

Propositional linear temporal logic (PLTL) extends propositional logic withoperators to denote time, see Table 2.1 [12]. PLTL thus allows formulas such as

G(speed > 0 → F (speed = 0))

to describe that “it is always true that something which moves will eventuallybecome still”.

8

Figure 2.2: A LBTest 2.x architecture

Formula Textual alternative Description⃝ϕ Xϕ ϕ is true in the next step in time□ϕ Gϕ ϕ is always true♢ϕ Fϕ ϕ is true or will be in the futureϕUψ ϕ is true until ψ is trueϕWψ ϕ is true unless ψ becomes true

Table 2.1: Operators in Propositional linear temporal logic [12].

9

PLTL can be used in conjunction with a model, e.g. one that is learned, toverify safety properties of a system or a larger system of systems.

2.4 Analysis of platooning systems

There are multiple ways in which a platooning system can be analyzed: analyti-cally, testing with a simulated platoon (which is done in this report) and testingwith actual road travelling vehicles (which is not discussed further).

An example of an analytic analyzing of a platoon is done in [7] where a contextaware retransmission scheme is used to analyze platoons of different length. Theauthors analyze the platoons with respect to a so called “packet reception ratio”against the length of a transmission (called super-frame), which is proportionalto the frequency of the messages. Calculations around the probability of themessage being received are done for different platoon lengths and super-framelengths. From [7] it can be noted that for high frequency messages the platoonlength is severely limited and vice versa, if the probability to receive a messagehas to be high the message frequency must be decreased for long platoons.

However an analytic analyzing only of a platooning system might fall short asthe vehicles behaviours’ might be hard to analyze analytically for any reasonablesized vehicle model, justifying a need to simulate the vehicles and the platoon.An example of this case is done in this report.

10

Chapter 3

The platooning simulator

It would be infeasible to drive around in actual vehicles in order to test theplatoon since this would take an enormous amount of time, would be bad forthe environment and probably result in a number of crashes and injuries for thevehicles’ drivers. Therefor a simulator, KTH PlatoonSim, is needed in order toevaluate the platoon algorithm.

Building upon the basis described in Chapter 2, this chapter first describessome characteristics of KTH PlatoonSim and goes on to define a high levelcommunication model which is added to the simulator. The communicationmodel is then extended with a notation of packets and a simple model for packetloss. Finally two different emergency braking strategies are defined, a cooperativeemergency braking protocol (CEBP) and a trivial emergency braking strategywhich only uses the vehicles’ CACC components. (CACC is an abbreviation forco-operative adaptive cruise control and is an extension of adaptive cruis controlor ACC.)

3.1 Introduction

In this report the KTH PlatoonSim platooning simulator is built upon andextended. It builds upon earlier work from [14]. For the purpose of the workdescribed in this report the simulator was extended with a new communicationmodel, described in Section 3.2, to enable the study of how non-perfect commu-nication affects the safety of the platoon during emergency braking. A methodto hold configuration parameters for each instance of a platoon was also added.

The simulator has the capability of simulating point mass model of a vehicleand running vehicles in a platoon of any fixed length. The simulator is one-dimensional, the vehicles can only accelerate and move forward, brake or standstill. Each vehicle is controlled by its gas and brake pedal and an ”e” buttonto start the emergency braking. Thus cruising on a highway can be simulated.Models of wheel slip rate and air resistance exist. Figure 3.1 illustrates how theparts of a simulated vehicle fit together.

11

VBW  VBW  VBW  VBW  

VBW  VBW   VBW  VBW  

VBW  ABS   VBW  ABS  

VBW  ABS   VBW  ABS  

VBW  GBC  VBW  BTC  VBW  CACC  

VBW  ODOM  

VBW  WCOM  

Driver  brake  pedal  

Driver  accel  pedal  

Brake  torque  request  

Brake  torque  request  

Brake  torque  request  

Brake  torque  request  

brake  

acc  

Host  loca>on  xh  velocity  vh  

Target  loca>on  xt  velocity  vt  

BBW  Subsystem  

Vi-­‐1  ,Vi+1  

Figure 3.1: A diagram of a simulated platoon vehicle.

In the simulator, time is discretized into ticks where each tick correspondsto one millisecond. Different parts are run with different resolutions, e.g. every10:th tick.

The ACC takes as input the position and velocity of the vehicle immediatelyin front, this data is sent as a status message from a vehicle vi to vi+1 (wherei ∈ {0..n− 2} in an ordered platoon of n vehicles).

The simulator is highly configurable:

• The platoon can have any positive length.

• The frequency of sending status messages can be set to any integer notsmaller than the number of vehicles in the platoon.

• One or more of the radio senders for CEBP messages can be disabled.

• One or more of the radio transmitters for CEBP messages can be disabled.

• The packet error rate for status messages can be controlled independentlyof the packet error rate for CEBP messages.

• There are options to provide output more detailed than standard, this isused for visualization.

• The type of communication: Broadcast or multi hop (i.e. packets arerelayed over point-to-point links)

12

Each platoon vehicle has two main modes, cruising and emergency braking.During cruising the CACC controls the vehicle, when the emergency braking isactivated the CACC is deactivated and the vehicle’s braking system activatesthe brakes resulting in the emergency braking having complete control over thevehicle.

3.2 The Vehicle Communication Model

This section describes the communication between the vehicles in the simulatedplatoon i.e. the radio channels, the multiple access scheme, the modelling ofthe radio transmissions, the transmission algorithm and finally the messagestructure.

An overview of how the messages travel is seen in Figure 3.2: data from thevehicle’s memory is read, a message is created and enqueued for transmission.At some point in time the radio is allowed to transmit, as defined by an slottedmultiple access scheme, and the highest priority message is sent over the radiochannel and the message is delivered to the receiving radio.

3.2.1 The radio channel

The radio channel modelled has been simplified both with respect to ITS G5and possible 5G implementations.

As for ITS G5 the following simplifications have been made:

• The multiple access scheme and collision detection and avoidance havebeen replaced with a slotted access scheme which is described below.

• CAM messages are not used. Instead status messages (only containing thevehicle’s speed and position) are sent with fixed frequency in contrast tothe 1-10 Hz variable frequency of CAM messages.

• DENM messages have been substituted for custom CEBP messages andare subject to the slotted access scheme.

As for a 5G cellular network, it can be noted that 5G has not yet beenspecified. However, the work described in this report assumes the following of afuture 5G network:

• The bandwidth of the wireless communication is assumed to be ”highenough”, in the order of 4 Mbit/s.

• A platoon-local broadcast mechanism is available

• Availability of either a ”for the platoon dedicated radio channel” with aslotted access scheme or a logical channel over i.e. UDP/IP where theslotted access scheme can be implemented.

13

VehicleStatus

RadioBlock

Vehicle 0

Vehicle 1

RadioBlock

VehicleStatus

Various parts of thevehicle read thevehicle state andcreate messages

RadioBlock transmits themessage with highestpriority and keeps the restin a queue

CommunicationControllerforwards the message to allradio blocks with broadcastor a single recipient withmultihop

RadioBlock makesrecieved messagesavailable

The receiversupdate the vehiclestate

CEB

CEB

cebp

cebp

cebp

cebp

position,velocity

position,velocity

RadioChannel

Figure 3.2: An overview of the communication between the vehicles, here withtwo messages of different types. The CEBP message is selected since its priorityis higher than the vehicle status message.

It is assumed the bandwidth is large enough so that multiple 500 bytemessages can be transmitted during the 1 ms simulator tick. A reasonableassumption is that a real world implementation could communicate over a 5Gcellular network with a bandwidth high enough to sustain the messages being

14

transmitted. Even though 5G is not standardized as of the time of writingrequirements listed in e.g. [19] indicate that a 5G network has high enoughcapacity and bandwidth to handle the communication modelled in this report.

3.2.2 The multiple access scheme

A new communication model had to be written to extend the platooning simulatorwith high level communication. The protocols implemented into the simulatorhad to be possible to use in a real world scenario, more specifically collisions inthe radio traffic had to be avoided in the communication model.

The CSMA/CD scheme used by 802.11p uses a random time back off startingon the order of micro seconds when a collision is detected [1].

The challenge with back off time being in the order of micro seconds isthat the platooning simulator is implemented with a granularity of 1 ms. Theconsequence of which is that the back off would be performed directly or duringthe next tick. Thus the back off would effectively be 0 ms or 1000 ms both ofwhich would be wrong. Furthermore there are other simulators such as OMNeTand Veins for actual simulation of the communication. With the goal of thisreport being to test the system of systems, accurate simulation of the radiocommunication is out of scope.

As a platoon is fairly static it has been proposed in [7] to use a TDMA schemeas a simple alternative instead of meeting the complex requirements the 802.11pnetwork stack requires. This is only feasible if the clock in each participatingradio is synchronized with the rest of the system, something which can be donewith GPS [4].

Another reason for choosing a TDMA scheme is that estimations for when apacket should have arrived are made easier since it is known when a message isdue to be sent, in contrast to the 802.11p collision avoidance where the exactpacket transmission times might be non-deterministic.

For the reason listed above a TDMA scheme implementing round robin isused to schedule the vehicles’ radio transmissions and every vehicle in an nvehicle platoon is allowed to transmit every n:th millisecond interval:

Let vi be the i:th vehicle in a platoon consisting of n vehicles, where 0 ≤ i < n.During any 1 millisecond interval t vi is allowed to transmit if

(t− i) ≡ 0 mod n (3.1)

An example is shown in Figure 3.3 where four vehicles A, B, C and D sendstatus messages si only at pre-allocated time slots.

3.2.3 The communication model

The communication is modelled with a radio channel and a radio. The radiochannel is shared between the vehicles whereas the radio is tuned to a singlechannel, enabling multiple radio channels to be in use the same tick. Effectivelyeach vehicle thus can have multiple radios.

15

Figure 3.3: Four vehicles A, B, C and D transmit their respective status messagesi every hundred time interval. Unused slots where the vehicle is allowed totransmit are blank whilst the remaining slots are marked by a cross (duringwhich the vehicle is not allowed to transmit).

Two types of radio links are available, broadcast and point-to-point betweenadjacent vehicles. As for broadcast communication, each message is heard byevery vehicle in the platoon. With multi-hop communication a message is passedfrom one vehicle to the next. In this case a message is passed forward or backwardin the platoon and vehicles in the message’s path will overhear the message.With a three vehicle platoon with vehicles v0, v1 and v2, a message m0 from v0to v2 is transmitted two times, from v0 to v1 and from v1 to v2 and is overheardby v1. Another message m1 sent from v1 to v0 is only transmitted this one timeand v2 has no knowledge about m1.

3.2.4 The transmission algorithm

The transmission algorithm is listed in Algorithm 1, each tick when the vehicleis allowed to transmit the message with the highest priority is removed from thetransmission queue and transmitted.

Algorithm 1 The algorithm to transmit messages

Input: A queue Q of messages sorted in descending priority.Input: The current time t.Input: The vehicle’s position in the platoon i.Input: The number of vehicles in the platoon n.if (t− i) ≡ 0 mod n then

m := first(Q)remove m from Qtransmit m

end if

16

3.2.5 Estimating an upper bound for the timeout valuesin CEBP

This section derives equations to calculate when any vehicle in the platoon shouldexpect to receive an ACK when it either sends or overhears an E-brake request.

Assume that the vehicles have indexes 0, 1, . . . n− 1 in an n vehicle platoonand that CEBP messages are sent as soon as possible.

From equation 3.1 it follows that any vehicle with index i is allowed totransmit at any time i = i+ k · n where k ≥ 0 denotes the TDMA cycle. Thisgives that if a vehicle Vi sends a message at time ti, the preceding vehicle Vi+1

can at the earliest send at time

ti+1 = ti + n− 1 (3.2)

Using broadcast communication, if any vehicle Vi sends an E-brake request attime ti = i+k ·n it should expect to receive an ACK at time t′i = n(k+n+1)+2:

Let a = n− i. Following equation 3.1, Vi sends at time t = n− a+ k · n =n(k + 1) − a. From equation 3.2 it follows that vehicle Vn−1 sends its ACKat time t = n(k + 1) − a + (n − 1), Vn−2 sends its ACK at t = n(k + 1) −a + (n − 1) + (n − 1), and so on. Finally Vi+1 sends its ACK to Vi at timet = n(k + 1)− a+ (a− 1)(n− 1) which results in that Vi should expect to havereceived the ACK at time t = n(k + 1) + (a− 1)(n− 1)− a+ 1. Substituting awe get t = n(k + 1) + (n− i− 1)(n− 1)− n− i+ 1 which is simplified to

t′i = n(k + n− i) + 2 (3.3)

For multi hop communication it takes n ticks for the message to reach thelast vehicle: If the lead vehicle V0 transmits an E-brake request at time t0 ≡ 0mod n to the last vehicle Vn−1 it is received by V1 at time t0 + 1. Note thatvehicle V1 is allowed to forward this message the same tick and the correspondingholds for the rest of the vehicles when the E-brake request is forwarded. Sincethe message needs to be forwarded n− 1 times the message is received by Vn−1

at time t0+n−1+1 = t0+n. Combining this with equation 3.2 an ACK shouldbe received by V0 at time

t′0 = n+ (n− 1)2 (3.4)

3.3 Packet loss

A simple model for packet loss is available as a feature in the simulator. Theprobability of a message being lost depends on two numbers, the base packeterror rate b and the distance between the sender and receiver. Messages can belost independently by two different receivers.

A linear model b + a · d was chosen for the calculation of the packet errorrate where b is the base packet error rate, a is the attenuation factor and dcorresponds to the distance between the sender and receiver.

17

Measurements done on a public Swedish motorway yields b = 3, 67% foradjacent vehicles and linear regression gives a = 18, 6 [2]. Thus the packet lossmodel is

P (message dropped) = 0, 0367 + 0, 186 · (|i− j| − 1)

where i and j are indexes of vehicles in the platoon.Since the distance for two adjacent vehicles is already accounted for in b,

the distance d is defined as d = |i− j| − 1 where i = j are indexes of vehiclesin the platoon. Note that for d ≥ 6 (e.g. a message from the lead vehicle withi = 0 to the eight vehicle with i = 7) every packet is lost to the receiver. (Anexample of a situation where a message is dropped is shown in Figure 3.4 whichhighlights that a single message can be received by some vehicles and lost toother vehicles.)

This model was developed together with Carl Bergenhem in [2] as a ”betterthan nothing” way of enabling packet loss into the communication where thelikelihood of a message being lost is increased with the distance between thesender and receiver. Accurate simulation of the radio waves is out of scope ofthis report.

18

Figure 3.4: An example where a broadcast message sent by vehicle 0 is receivedby vehicles 1 and 2 whilst lost to vehicle 3.

3.4 Messages

This section describes the abstract messages that are transmitted. The messagesalways consist of the following fields:

• sender, the index of the transmitting vehicle.

• receiver, the index of the receiving vehicle.

• type, STATUS or CEBP.

• data, the payload of the message.

In the case of multi hop communication two additional fields are set:

• nextRecipient, the vehicle index the multi hop message is actually trans-mitted to until it reaches its final recipient receiver.

• isMultihop, a boolean value set to true

The type and whether the message is multi hop is used to derive the messagepriority: Each message m has a priority defined as

priority(m) =

⎧⎪⎨⎪⎩100 if m.type = CEBP

50 if m.type = STATUS

1 otherwise

+

{1 if msg.isMultihop = true

0 otherwise

3.5 The emergency braking strategies

This section describes the three emergency braking methods: A cooperativeemergency braking protocol (CEBP), a trivial CACC emergency brake and acombination of both.

19

3.5.1 The cooperative emergency braking protocol

The cooperative emergency braking protocol which is presented in algorithm 2,was designed by Carl Bergenhem as part of the SafeCop project. The goal of thealgorithm is to bring a platoon to a complete stop in a more efficient mannercompared to only using the vehicles’ CACC components to actuate the braking.Figure 3.5 describes the same protocol in a diagram. In essence the protocolensures that no vehicle starts braking before its immediately succeeding vehiclehas acknowledged that it has started braking, unless the immediately succeedingvehicle fails to receive the emergency braking request, in which case the vehiclestarts braking when a timeout threshold is reached.

Algorithm 2 Pseudo code describing CEBP

1: if Ego Vehicle Vi wants to e-brake then2: send “E-brake request” to last vehicle VN-1

3: end if4: if ”E-Brake directly” is received by Ego Vehicle Vi then5: send “E-brake request” to last vehicle VN-1

6: end if7: if Ego Vehicle Vi (has sent “E-brake request” command) or (overheard“E-brake request” from Vj) then

8: prepare brake system9: Start Ti

10: end if11: if “E-brake request” is received by Ego Vehicle Vi from a preceding vehicle

Vj, where j ∈{0..i-1} then12: Ego Vehicle Vi actuate e-brake strategy13: send “E-brake ACK” to the next preceding vehicle Vi-1

14: end if15: if “E-brake ACK” is received by Ego Vehicle Vi from next succeeding vehicle

Vi+1 then16: Ego Vehicle Vi actuate e-brake strategy17: Stop Ti

18: if i > 0 and has not already sent an “E-brake ACK” to preceding then19: send “E-brake ACK” to the next preceding vehicle Vi-1

20: end if21: send “E-brake ACK” to the next preceding vehicle Vi-1

22: end if23: if Ti expires then24: Ego Vehicle Vi actuate e-brake strategy25: send “E-Brake directly” to all succeeding vehicles Vj, where j∈{i+1..N-1}26: send “E-brake ACK” to the next preceding vehicle Vi-1

27: end if28: if Ti is started then29: decrease Ti

30: end if

20

Figure 3.5: A presentation of CEBP using automata.

21

3.5.2 CACC emergency brake

CACC emergency brake is an ad hoc method of doing emergency brake: Whenthe emergency brake is activated in the lead vehicle its CACC actuates maximumbrake pedal. The next scheduled status message that is sent to the immediatelysucceeding vehicle is updated to tell the immediately succeeding vehicle that italso should actuate CACC emergency brake. Since CACC status messages aretransmitted every 100 ms it may take several hundred milliseconds for the lastvehicle in the platoon to start braking.

3.5.3 CEBP and CACC emergency brake combined

To minimize the time before every vehicle in the platoon enters a braking stateCEBP and CACC emergency brake is combined: When the emergency brakeis activated in the lead vehicle it initiates CEBP and also activates its CACCemergency brake. This leads to the lead vehicle braking earlier than with onlyCEBP.

22

Chapter 4

Methods

Building upon the simulator described in Chapter 3 this chapter describes abinary search method, then a random testing tool for KTH PlatoonSim to testthe hypothesis from Chapter 1. Finally a tool to visualize the platoons areshown.

Two different approaches were considered, an approach using learning basedtesting and one approach using random testing. Early attempts were madewith learning based testing but the learned models were too large for the modelchecker and so the learning based testing approach was deemed to take too muchcomputing time to be feasible. In contrast random testing was only limited tothe simulation execution time.

4.1 The binary search method

A binary search method, described in Algorithm 3 is constructed to find a platoonwith no crashes, where a crash is defined as “the inter-vehicle distance betweenany two vehicles is less than or equal to zero”.

The simulator is used to create different platoons with varying parameters.For each particular platoon the minimum safe time headway between the vehiclesis determined by executing random tests and counting the number of crashes.The time headway is deemed safe for a particular platoon if there are no crashesin any of the test cases. This together with the simulator forms a Monte Carloalgorithm to find the minimum time headway fast.

As described earlier there are three emergency braking strategies present inthe simulator:

• CACC emergency brake

• CEBP

• CACC + CEBP, the combination of both

A test wrapper is written which bridges input and output between testingtool and the platooning simulator enabling the platoon itself to be tested.

23

Algorithm 3 The binary search method to find the minimum time headway.The input parameters can be tuned in order to run fewer tests, in the beginningthe values have to be estimated. Note that hwmax should be selected in aneducated way to actually find a headway with no crashes.

Input: The maximum time headway to test hwmax.Input: The minimum time headway to test hwmin.Input: The tolerance when calculating the minimum headway tolerance.Variable: hwprev := ∞ denotes the previous found headway.Variable: The time headway hw := 0while |hw − hwprev| > tolerance or there are crashes do

hw = (hwmax + hwmin)/2Run tests with the headway hwif there are crashes then

hwmin := hwelse

hwmax := hwend ifhwprev := hw

end whileOutput: The found time headway hw.

4.2 The random testing tool

The random testing tool generates a test suite of 10 000 random test casesand varies the inter-vehicle time gap using the binary search method until theminimal safe time gap is found within a precision of 0,01 seconds. (The reasoningto use 104 test cases and not 103 or 105 test cases is rather arbitrary. Thenumber of test cases ought to be large as to simulate a larger driving distancebut low enough so that the simulations and tests are done in a feasible time.)

A simple model checker is used as the test oracle to evaluate each test case:The test case fails if and only if any vehicle reports a crash to the one immediatein front (where a crash is defined as the inter-vehicle distance ≤ 0). This modelchecker however is hard coded in the implementation and is not expressed witha high level logical language such as PLTL or even propositional logic.

KTH PlatoonSim is controlled by sentences of commands from a systemspecific alphabet. The alphabet consists of four types of commands:

• Acceleration commands, a1, a2, . . . , a10 which corresponds to 10, 20, . . . ,100 % of gas pedal actuation.

• Braking commands, b1, b2, . . . , b10 which corresponds to 10, 20, . . . , 100% of braking pedal actuation.

• A special no-op 0 command which does nothing.

• Emergency braking commands, e (activate CEBP) bE (activate CACC

24

Emergency braking strategy SuffixCEBP e,0,0,0,0,0

CACC emergency braking bE,bE,bE,bE,bE

CEBP + CACC cc,cc,cc,cc,cc,cc

Table 4.1: The suffixes used for different emergency braking strategies.

Symbol Acceleration Meaninga7 +1,4 m/ss Actuate 70 % gas pedalb4 -1,2 m/s2 Actuate 40 % brake pedal0 0 m/s2 The no-op command, do nothinge -2,2 m/s2 Activate emergency braking with CEBPbE -2,2 m/s2 Activate CACC emergency brakecc -2,2 m/s2 Activate the combined emergency brake

Table 4.2: The acceleration values for the simulator symbols used as well as theirmeaning. Note that all commands a10..a1 and b10..b1 are implemented but notused.

emergency braking) and cc (activate the combination of CEBP and CACCemergency braking).

Each command is enacted by the lead vehicle for a period of 5 seconds beforeswitching to the next one in the sentence. The following vehicles uses theirCACC algorithms to follow in the platoon. An arbitrary example sentence forthe simulator is a3,a7,a10,0,0,b4,b4 which would correspond to a slow butincreasing acceleration, followed by a released gas pedal before braking.

For the particular work being done in this report the commands used area7 and b4. As seen in Table 4.2 these commands corresponds to reasonableacceleration and braking speeds.

Each test case is generated as a random string of the commands followed byan emergency braking suffix, which leads to that the lead vehicle is either in anaccelerating mode or a braking mode. Experience with the simulator shows thatthis type of gas-and-brake driving is challenging for the CACC algorithm and isused to provoke the system into a bad state before performing the emergencybrake. The number of symbols is limited to these two to keep the space ofpossible test cases small, 220 ≈ 106 compared to 2020 ≈ 1026.

There are three different emergency braking suffixes, seen in Table 4.1.Table 4.2 presents symbols, meaning and the corresponding acceleration or

braking effect in m/s2 for all symbols used during the testing. The emergencybraking is performed with 100 % brake pedal (which is b10 for the simulator).

Each random string consists of 20 symbols, thus each test case corresponds to100 seconds of driving and each test suite corresponds to 278 hours of continuousdriving.

Using random combinations of a7 and b4 as described above, examples ofpossible test cases are as follows (except for the emergency braking suffixes):

25

1. a7,b4,b4,a7,b4,a7,b4,b4,b4,b4,a7,a7,a7,b4,a7,b4,b4,b4,b4,b4

2. b4,b4,a7,b4,b4,b4,b4,b4,b4,a7,a7,a7,b4,b4,b4,b4,a7,a7,a7,a7

3. a7,b4,a7,b4,a7,b4,b4,b4,a7,b4,a7,b4,a7,a7,a7,b4,a7,b4,a7,b4

It can be seen that there is no built-in structure such as “accelerate, cruise for abit and then brake”, since random testing is used the platoon behaviour is muchmore random. For example: with test sequence 1, the platoon “accelerates for 5seconds, brakes for 10 seconds, accelerates for 5 seconds, brakes for 5 seconds...”and so on.

4.3 The visualization tool

The test results returned by the test tool are not easily readable or understandablefor a human. In particular two things prevent an intuitive understanding of thebehaviour:

• A series of numbers are returned for the positions and velocities of thevehicles and it is hard to get an overview of a moving system by readingsamples of the state.

• The simulator is sampled every five seconds which leaves a rather large gapwhere emergent properties occur which is hard to observe from positionand speed samples alone.

For these reasons a visualization tool was developed, see in Figure 4.1. Usingthis tool a test case can be analyzed and stepped through with a resolution of15 ms. A number of parameters can be configured: the number of vehicles, thetime headway, the command sequence, whether packet loss is enabled and ifthere shall be any broken radio units in any vehicle.

An example test case is seen in Figure 4.2 which results in a crash due to thesecond vehicle having a much higher velocity than the first during the braking.

26

Figure 4.1: The platoon visualization tool. The values shown are lateral position,velocity and acceleration.

27

Figure 4.2: The second vehicle have a much higher velocity than the first duringthe braking which results in a crash.

28

Chapter 5

Testing results

This chapter describes results obtained from running the random testing tooldescribed in Chapter 4 in four different configurations: with two differentcommunication strategies, broadcast and multi hop, and with or without thepacket loss model.

5.1 Introduction

This section overviews the results from the testing, the minimal safe timeheadways (defined below) and comparisons between the different emergencybraking strategies with different lengths of the platoon and with or without thelinear packet loss model.

There are two ways of describing the distance between two vehicles in aplatooning system: the distance and the time gap, the time gap obviously varieswith the vehicles’ speeds. Inter-vehicle time gap is used in this report and thusthe minimal safe time headway is defined as the minimal inter-vehicle time gap tsuch that if the vehicles all keep the time gap t there are no crashes. (Rememberfrom Chapter 4 that a crash is defined as the inter-vehicle distance is less thanor equal to 0.)

There are four different communication scenarios tested by using differentcommunication strategies (broadcast and multi hop) with or without packet loss.The test results can be summarized as follows (also seen in Table 5.1).

For broadcast communication and packet loss CACC emergency brake per-forms the worst and the combination, CEBP + CACC, performs the best withan improvement of 3.3 % over CACC emergency brake. For multi hop communi-cation and packet loss CEBP performs the worst and the combination of bothstrategies performs the best.

With no packet loss CACC emergency brake performs on average slightlybetter than CEBP and the combination. However, it is worth noting that thisdifference is on the order of 1 %.

The graphs and tables are presented in the following order: first graphs for

29

Broadcast communication Multi hop communicationPacket loss CEBP + CACC performs

the bestCEBP + CACC performsthe best

No packet loss CACC performs slightlybetter than CEBP

There are no large differ-ences

Table 5.1: A summary of the test results.

broadcast and multi hop communication respectively with packet loss followedby tables with comparisons. Thereafter the corresponding graphs and tables arepresented for measurements with no packet loss.

5.2 Test results

The main results are listed as follows: First a summary of the results is seen inTable 5.1. Then measurements and tests with the packet loss model enabledare shown (in Figures 5.1 and 5.2 and Tables 5.2 through 5.4) and finally themeasurements and results with no packet loss model are shown (in Figures 5.3and 5.4 and Tables 5.5 through 5.7).

30

0,00

0,20

0,40

0,60

0,80

1,00

1,20

1,40

1,60

1,80

0 1 2 3 4 5 6 7 8

Min

imu

m t

ime

hea

dw

ay w

ith

0 c

rash

es

Number of vehicles

Broadcast, packet loss

CEBP CACC CEBP + CACC

Figure 5.1: Broadcast communication with packet loss

CEBP performs slightly better than the combination of CEBP and CACCthough the combination is not far behind. However for this particular test runthere is a sweet spot at 5 vehicles which balances the number of vehicles againstthe time headway needed to have no crashes.

0,00

0,20

0,40

0,60

0,80

1,00

1,20

1,40

1,60

1,80

2,00

0 1 2 3 4 5 6 7 8

Min

imu

m t

ime

hea

dw

ay w

ith

0 c

rash

es

Number of vehicles

Multihop, packet loss

CEBP CACC CEBP + CACC

Figure 5.2: Multi hop communication with packet loss

31

With multi hop communication the probability of a single packet beingdropped is smaller since the distance is only 1 vehicle. Here an advantage canbe seen for the combination of CEBP and CACC with the sweet spot being aplatoon length of 4 vehicles.

32

Comparison Mean improvement Median improvementCEBP vs. CACC 2.3 % 2.5 %

CEBP + CACC vs. CACC 3.3 % 2.2 %CEBP + CACC vs. CEBP 0.6 % 1.1 %

Table 5.2: Comparison of different emergency brake strategies with broadcastcommunication and packet loss. The combination of CEBP and CACC performsslightly better in the average case.

Comparison Mean improvement Median improvementCEBP vs. CACC -2.6 % 1.1 %

CEBP + CACC vs. CACC 1.3 % 3.1 %CEBP + CACC vs. CEBP 3.7 % 3.7 %

Table 5.3: Comparison of different emergency brake strategies with multi hopcommunication and packet loss. It can be noted that in this case solely usingCEBP might perform worse and adding in CACC as well results in a betterbraking strategy with regards to the time headway.

N Broadcast Multi hop2 -0,021 -0,1413 0,141 0,0884 0,146 0,2935 0,017 0,1356 0,056 0,0147 -0,004 -0,079

Table 5.4: The difference in seconds between CEBP+CACC and CACC fordifferent platoon lengths and communication methods, using the linear model forpacket loss. This show that the choice of emergency braking strategy is important,for example 4 vehicles with multi hop communication would correspond to adifference of 7 meters with the platoon driving at 90 km/h.

33

0

0,2

0,4

0,6

0,8

1

1,2

1,4

0 1 2 3 4 5 6 7 8

Min

imu

m t

ime

hea

dw

ay w

ith

0 c

rash

es

Number of vehicles

Broadcast, no packet loss

CEBP CACC CEBP + CACC

Figure 5.3: Broadcast communication with no packet loss. There is barely anydifference between the braking strategies.

0

0,2

0,4

0,6

0,8

1

1,2

1,4

0 1 2 3 4 5 6 7 8

Min

imu

m t

ime

hea

dw

ay w

ith

0 c

rash

es

Number of vehicles

Multihop, no packet loss

CEBP CACC CEBP + CACC

Figure 5.4: Multi hop communication with no packet loss. There is barely anydifference between the braking strategies.

With perfect communication, i.e. no packet loss, the difference is small

34

between the braking methods. Should this always be the case, probably thesimplest method ought to be chosen.

35

Comparison Mean improvement Median improvementCEBP vs. CACC -0.61 % -0.61 %

CEBP + CACC vs. CACC -0.82 % -1.67 %CEBP + CACC vs. CEBP -0.22 % 0.08 %

Table 5.5: Comparison of different emergency brake strategies with broadcastcommunication and no packet loss. In this case solely using CACC would be thebest choice.

Comparison Mean improvement Median improvementCEBP vs. CACC -1,43 % -0,69 %

CEBP + CACC vs. CACC -1,48 % -1,18 %CEBP + CACC vs. CEBP -0,03 % -1,37 %

Table 5.6: Comparison of different emergency brake strategies with multi hopcommunication and no packet loss. Also in this case solely CACC would be thebest choice.

N Broadcast Multi hop2 -0,013 0,0273 0,013 0,0384 0,028 0,0035 0,042 0,0126 0 -0,0037 -0,020 -0,025

Table 5.7: The difference in seconds between CACC and CEBP for differentplatoon lengths and communication methods, with no packet loss. The differencescorrespond to less than a meter of distance headway at 90 km/h.

36

Chapter 6

Discussion and conclusions

This chapter discusses the results from Chapter 5: first the testing method isevaluated and then the test results themselves are discussed. In the end possiblefuture work is reviewed.

6.1 Evaluation of the testing method

The approach described in this report can partly be used to perform requirementstesting on a system of systems: The method of random testing is simple to use,especially in this case where the test oracle can be defined as a simple to evaluatestatement such as “is there a crash in the test result?”. With some backgroundin software testing the tooling is easy to construct and if a large enough numberof test cases are generated and executed guarantees such as “when driving in theworst possible way there is a crash more seldom than D km” for some drivendistance D.

However when driving in a more general manner, for example when all symbolsa1 . . . a10 and b1 . . . b10 are used the space of possible test cases becomes verylarge very quickly which effectively prevents any reasonable test coverage. Forthese particular test cases 10 000 test cases out of a test case space of 220 ≈ 106,approximately 1 % of possible test cases were executed, test execution time andavailable computing power is a limiting factor.

On the subject of test coverage there is no way to know how well the platoonis actually tested besides the above mentioned more than D km before a crashoccurs.

Furthermore there are many limitations in the simulator: There is no en-gine model and it is one-dimensional (and thus cannot simulate turns or laneswitching). An engine model could affect the simulation since it would applyengine braking when there is no acceleration. The CACC algorithm used isalso a primitive one since there is no “look ahead” to vehicles in front of theimmediately preceding vehicle, i.e. any vehicle only has information regardingthe one immediately preceding. Furthermore the communication models are on

37

a high level with no simulation of how the radio waves and their message packetswould behave in an actual real-world scenario. Note, however, that there is awheel model including slippage for ABS braking.

To conclude, random testing with the binary search method could be usedas a quick pointer before more extensive verification and testing is done which isneeded for safety critical applications.

6.2 Discussion of the results

From [16] it can be concluded that a coordinated braking strategy which islimited by the slowest breaking vehicle is needed for safe platoon braking. Thisis related to behaviour seen with KTH PlatoonSim, in some cases there exists avehicle much faster than the immediately preceding one. This often results incrashes since the applied deceleration force is not enough to stop the vehicle in

time to avoid crashes. Since the kinetic energy Ek = mv2

2 the use case cannotdirectly be translated to a faster vehicle but the behaviour of needing too muchenergy to bring the vehicle to a stop in time is still seen in this report and in[16].

One thing is interesting to reason about, the case where CEBP is consideredover CACC: The result is that CEBP which starts braking from the end of theplatoon enables a lower time headway than CACC emergency braking fromthe beginning of the platoon. It can be argued that this is the scenario whichcorresponds to a hypothetical real world platoon since there is packet loss in thereal world and emerging 5G applications would enable broadcast communication.

However, the necessity for starting braking from the end of the platoon seemsto be smaller when the communication is perfect as seen in the simulation withno packet loss.

One emerging property that can be observed using the visualization tool isthat it is quite easy to make the vehicles in the platoon end up in a state whereone vehicle is braking whilst the immediately succeeding vehicle is acceleratingto decrease the distance between the vehicles. Often this results in a crash andit is quite possible that it is this property that requires the time headway to beas large as it is. An example is seen in Figure 6.1.

To summarize it seems that the combination of CEBP and CACC wouldbe the best emergency braking method in a multi hop communication scheme,whilst with a broadcast communication scheme CEBP can perform better.

6.2.1 Validity of results

A pre-existing foundation, KTH PlatoonSim for the simulator is used andextended, which yields some reasonable vehicle dynamics in the simulatedsystem.

38

V0 V1 V2

Traveling direction

V0 V1 V2

V0 V1 V2

V0 V1 V2

2

1

3

4

V0 V1 V25

Figure 6.1: An example of an impending collision. In step 1 the vehicles travelat some steady state and V0 begins to accelerate. In step 2 V1 is too far behindV0 so it accelerates to lessen the gap. In step 3 V1 has returned to its desiredheadway with respect to V0 but V2 begins to accelerate. The bad thing happensin step 4 where V0 performs some (emergency) brake and thus V1 (which travelswith the same speed and acceleration as V0) also brakes. However, V2 is still inan accelerating state or travels much faster than V1 and does not have enoughbraking capabilities to avoid crashing into V1 which is seen in step 5.

6.3 Future work

Some future work could be to replicate these results, to extend the simulator andto construct more detailed LTL formulas for the test case oracle. An example ofa possible LTL formula is

G(distance > 0 ∧ speed > 0 → F (speed = 0))

which translates to “the distance is always greater than zero and a speed greaterthan zero always results in the coming to a stop”.

The communication model used in this report is far from the standardized802.11p and provide no modelling at all of radio waves or how they interact with

39

the environment. The testing could be replicated in a simulator where this isprovided.

Second the vehicle model currently in use has limitations such as lack ofan engine model and the weight of each vehicle is the same and fixed. Thesimulator could be extended to incorporate elements such as these. Furthermorethe simulator is one-dimensional and could be extended to support lane changingand turning.

Finally more work could be done on the verification of the protocols: Forexample the driving requirement could be divided into two phases, one cruisingphase were the vehicles must never be too close nor too far from each other andan emergency braking phase were the requirements are relaxed into no crashes.

40

Bibliography

[1] IEEE Standards Association et al. “802.11-2012-IEEE Standard for In-formation technology–Telecommunications and information exchange be-tween systems Local and metropolitan area networks–Specific require-ments Part 11: Wireless LAN Medium Access Control (MAC) and PhysicalLayer (PHY) Specifications”. In: Retrived from http://standards. ieee.org/about/get/802/802.11. html (2012).

[2] Carl Bergenhem, Karl Meinke, and Fabian Strom. “Quantitative safetyanalysis of a coordinated emergency brake protocol for vehicle platoons”. In:International Symposium on Leveraging Applications of Formal Methods.Springer. 2018, pp. 386–404.

[3] Carl Bergenhem et al. “Overview of platooning systems”. In: Proceedingsof the 19th ITS World Congress, Oct 22-26, Vienna, Austria (2012). 2012.

[4] Katrin Bilstrup. A survey regarding wireless communication standardsintended for a high-speed vehicle environment. 2007.

[5] Katrin Bilstrup et al. “On the ability of the 802.11 p MAC methodand STDMA to support real-time vehicle-to-vehicle communication”. In:EURASIP Journal on Wireless Communications and Networking 2009.1(2009), p. 902414.

[6] Annette Bohm, Magnus Jonsson, and Elisabeth Uhlemann. “Performancecomparison of a platooning application using the IEEE 802.11 p MACon the control channel and a centralized MAC on a service channel”.In: Wireless and Mobile Computing, Networking and Communications(WiMob), 2013 IEEE 9th International Conference on. IEEE. 2013, pp. 545–552.

[7] Annette Bohm et al. “Context-aware retransmission scheme for increasedreliability in platooning applications”. In: International Workshop onCommunication Technologies for Vehicles. Springer. 2014, pp. 30–42.

[8] Joe W Duran and Simeon C Ntafos. “An evaluation of random testing”.In: IEEE transactions on software engineering 4 (1984), pp. 438–444.

[9] EN ETSI. “302 637-2 V1. 3.2,“”. In: Intelligent transport systems (ITS) ().

[10] EN ETSI. “302 637-3 V1. 2.2 (2014-11) Intelligent Transport Systems(ITS)”. In: Vehicular Communications ().

41

[11] EN ETSI. “302 663 (V1. 2.1)(11-2012):” Intelligent Transport Systems(ITS)”. In: Access layer specification for Intelligent Transport Systemsoperating in the 5 ().

[12] Michael Fisher. An introduction to practical formal methods using temporallogic. John Wiley & Sons, 2011.

[13] Richard Hamlet. “Random testing”. In: Encyclopedia of software Engi-neering (1994).

[14] Karl Meinke. “Learning-based testing of cyber-physical systems-of-systems:a platooning study”. Submitted to EPEW 2017.

[15] Karl Meinke and Muddassar A Sindhu. “LBTest: a learning-based testingtool for reactive systems”. In: Software Testing, Verification and Validation(ICST), 2013 IEEE Sixth International Conference on. IEEE. 2013, pp. 447–454.

[16] Dharshan Krishna Murthy and Alejandro Masrur. “Braking in CloseFollowing Platoons: The Law of the Weakest”. In: Digital System Design(DSD), 2016 Euromicro Conference on. IEEE. 2016, pp. 613–620.

[17] Jeff Offutt and P Amman. “Introduction to software testing (p. 27)”. In:Cambridge: Cambridge UniversityPress (2008).

[18] ACEA European Automobile Manufactureres Organization. What is truckplatooning. 2017.

[19] Afif Osseiran et al. “Scenarios for 5G mobile and wireless communications:the vision of the METIS project”. In: IEEE Communications Magazine52.5 (2014), pp. 26–35.

[20] Umit Ozguner, Tankut Acarman, and Keith Redmill. Autonomous groundvehicles. Artech House, 2011.

[21] Kimihiko Rencheng Zheng et al. “Study on Emergency-Avoidance Brakingfor the Automatic Platooning of Trucks”. eng. In: Intelligent TransportationSystems, IEEE Transactions on 15.4 (2014), pp. 1748–1757. issn: 1524-9050.

[22] Katrin Sjoberg. “Slides for ”Workshop on Wireless Vehicular Communica-tions””. Workshop at Halmstad University. 2015.

[23] S. Tsugawa, S. Kato, and K. Aoki. “An automated truck platoon forenergy saving”. In: IEEE International Conference on Intelligent Robotsand Systems. 2011, pp. 4109–4114. isbn: 9781612844541.

42

TRITA -EECS-EX-2019:73

www.kth.se