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
Quantitative Requirements Testing for
Autonomous Systems-of-Systems: Case Studies in
Platooning
Masters Thesis in Computer Science
Fabian Str¨ om
[email protected]
Examiner: Joakim Gustafsson Supervisor: Karl Meinke
February 26, 2019
Abstract
A platoon, or a road train, has many different benefits such as safety, fuel efficiency and road utilisation. However it must also be safe to use and must thus be thoroughly tested. This report looks at the specific use case of emergency braking using three different emergency braking strategies and two models of communication. A cooperative emergency braking strategy, a naive emergency braking strategy and the combination of both are tested. It is found that the combination of both performs the best.
Sammanfattning
En platoon, eller ett v¨agt˚ag, har m˚anga f¨ordelar s˚asom br¨ansleeffektivitet och v¨agutnyttjande. D¨aremot m˚aste den ocks˚a vara s¨aker att anv¨anda och d¨arf¨or grundligt testad. Denna rapport beaktar det specifika anv¨andarfallet n¨odbromsning genom tre olika n¨odbromsstrategier och tv˚a modeller f¨or kom- munikation. En samarbetande n¨odbromsstrategi, en naiv n¨odbromsstrategi och kombinationen av de tv˚a testas. Resultatet ¨ar att kombinationen av de tv˚a presterar b¨ast.
Contents
1 Introduction 3
1.1 Hypothesis . . . 4
1.2 Structure of the report . . . 4
1.3 Sustainable development . . . 4
1.4 Acknowledgments . . . 4
2 Background 5 2.1 Platooning . . . 5
2.2 Communication . . . 6
2.3 Testing . . . 7
2.3.1 Random testing . . . 8
2.3.2 Learning based testing . . . 8
2.3.3 Propositional linear temporal logic . . . 8
2.4 Analysis of platooning systems . . . 10
3 The platooning simulator 11 3.1 Introduction . . . 11
3.2 The Vehicle Communication Model . . . 13
3.2.1 The radio channel . . . 13
3.2.2 The multiple access scheme . . . 15
3.2.3 The communication model . . . 15
3.2.4 The transmission algorithm . . . 16
3.2.5 Estimating an upper bound for the timeout values in CEBP 17 3.3 Packet loss . . . 17
3.4 Messages . . . 19
3.5 The emergency braking strategies . . . 19
3.5.1 The cooperative emergency braking protocol . . . 20
3.5.2 CACC emergency brake . . . 22
3.5.3 CEBP and CACC emergency brake combined . . . 22
4 Methods 23 4.1 The binary search method . . . 23
4.2 The random testing tool . . . 24
4.3 The visualization tool . . . 26
5 Testing results 29
5.1 Introduction . . . 29
5.2 Test results . . . 30
6 Discussion and conclusions 37 6.1 Evaluation of the testing method . . . 37
6.2 Discussion of the results . . . 38
6.2.1 Validity of results . . . 38
6.3 Future work . . . 39
Bibliography 41
Chapter 1
Introduction
We live in a world where more and more systems are becoming digitalized and computer systems are becoming integral to many things in everyday life. These systems can have high degrees of complexity and more often than not more than a single manufacturer is involved in creating a finished product. Of course this product needs to be tested to ensure safe operation, a difficult task since details of one part of the system or source code is most likely not available for another manufacturer. Intellectual property rights and the natural secrecy of manufacturing companies make the task of software and hardware testing even more difficult; each part of a system is a system itself, rendering the product a system of systems.
This report describes a method for testing such a system of systems for the problem of platooning. In contrast to self driving cars, another emerging product, a platoon is composed of several vehicles that together form a unit on the motorway by driving close to each other to form a “road train”, with the goal 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 be manufactured by different manufacturers and each truck is composed of a number of subsystems each interacting with each other.
Platoons are studied with respect to qualitative safety were high level logical statements are used to find safe platoons. Furthermore quantitative safety is discussed by using sensitivity analysis and parameter tuning to find the optimal safe configuration of any found safe platoon.
A case study is performed on coordinated emergency braking of a platoon by comparing three methods for performing the braking, a distributed cooperative protocol, a naive emergency braking and a combination of both. The goal is to determine the minimum constant time gap between the vehicles where there are no inter-vehicle crashes. A Monte Carlo algorithm is constructed to evaluate various platoon configurations.
1.1 Hypothesis
The hypothesis for this report is that a binary search method (also known as the interval halving method) can be used with automated testing to find the minimal 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 in Chapter 2 with the simulator and communication scheme used for the testing is detailed in Chapter 3. The methods used to evaluate the platoon is given in Chapter 4 whilst the test results are presented in Chapter 5. Finally conclusions are made and discussed in Chapter 6.
1.3 Sustainable development
Economical, social and ecological aspects of sustainable development is not applicable 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 platooning itself 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 Carl Bergenhem for his extensive knowledge of the area and many interesting and informative discussions.
The research leading to these results has been performed in the SafeCOP project, that received funding from the ECSEL Joint Undertaking under grant agreement 692529, and from Vinnova Swedish national funding.
Chapter 2
Background
This chapter provides a background to the work described in this report: first platooning overall is described followed by an overview to the radio schemes applicable to platooning. Finally methods for testing are described and different ways of a analyzing a platooning system.
2.1 Platooning
A platoon, also called a road train, can be described as a number of vehicles travelling together with short inter-vehicle gaps [22] and can be seen as a cooperative cyber-physical system of systems (Co-CPS) [2]. Figure 2.1 shows a simple 1-dimensional platoon with 3 vehicles with the inter-vehicle gap marked.
Figure 2.1: A 1-dimensional platoon with three vehicles, V0, V1and V2. In the past decades there have been several projects related to platooning (the concept of having vehicles travelling in a platoon) such as SARTRE, PATH, GCDC, Energy ITS and SCANIA Platooning [3]. All these projects, whilst having a similar goal of enabling vehicle platooning, have different demands on the roads and infrastructure, ranging from none to dedicated platooning lanes equipped with markers.
Platooning is beneficial for the safety, fuel efficiency and road utilization in traffic:
The safety is increased as a fully automatic braking decreases the reaction time compared to a human since the system can react faster and no human needs to 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
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 gaps are reduced [16]. Within the Energy ITS project a platoon of 3 vehicles travelling at 80 km/h with a inter-vehicle gap of 10 m measured fuel savings at 14 % for the platoon [23]. Moreover, carbon dioxide emissions can be reduced [18], for example the Energy ITS platoon measured savings of 2.1 % in a macroscopic view with 40 % usage of platoons for heavy vehicles [23].
Finally, the number of vehicles on the road can be increased by reducing the inter-vehicle gap making the road utilization more efficient [18].
For a road travelling vehicle there are two forms of control: longitudinal control can be described as forward/backward on the road whilst lateral control
enables lane switching and turns.
In a platooning system the longitudinal control is used to control the distance to the vehicle in front [20]. To keep the safety benefits of platooning the longitudinal control needs to control the braking and emergency braking. It can be noted that the platoon shall not brake harder than what the braking vehicle with the most limited braking capabilities can manage [16]. If this were to be done, the vehicle behind the most limited vehicle would crash into the most limited vehicle.
However, a platoon unable to take turns or switch lanes would be rather limited and so for a fully automated platoon lateral control is also needed. For example SCANIA and GCDC platoons have manual lateral control [3].
2.2 Communication
Wireless communication for V2x (which stands for Vehicle to vehicle and Vehicle to infrastructure) in the European Union is defined in the European Standard ETSI ITS G5 (European Telecommunications Standards Institute Intelligent Transport Systems) which is based on IEEE 802.11-20121 [11].
For wireless communication the 802.11 standard describes the 802.11p physical layer for V2x communication [20], 802.11p uses a Carrier Sense Multiple Access scheme with Collision Avoidance (CSMA/CA) [6].
To avoid collisions on the radio channel the sender listens to the channel for some predetermined period and if the channel is free the transmission is performed. If the channel is not free the sender randomly selects a period to wait before performing the transmission. However it only counts down when the channel is free [5].
ETSI ITS G5 defines two message types that are of interest:
• Cooperative Awareness Messages (CAMs) are periodically sent messages containing 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.
• Decentralized Environmental Notification Messages (DENMs) are triggered by 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 identifies four channels to use where each channel has a theoretical maximum bandwidth of 27 Mbit/s [20]. With e.g. a platoon of 7 vehicles and status messages every 10 ms the bandwidth needs to be 2.8 Mbit/s for each platoon. Furthermore, there is a back off between messages during collision avoidance, making 802.11 unreliable [6]. Thus it has been proposed in [7] to preschedule the communication within a 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 specific vehicle is allowed to transmit at any specific time.
2.3 Testing
Software testing can be divided into two areas, white-box testing and black-box testing. With white-box testing the tester has knowledge of the internal structure of the system under test. With black-box testing the tester only have access to external descriptions of the system under test [17]. White-box testing will not be discussed further.
Conceptually black-box testing can be viewed as regarding the system under test as a “black box” where the inputs is processed by some unknown function or 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 determines this 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 test forms a test case, together with pre- and postfix values [17].
• Test requirement ”A test requirement is a specific element of a software artifact that a test case must satisfy or cover.” [17]
• Requirements testing – Testing the system with respect to high level requirements 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 for each level. Three main levels are unit testing, integration testing and system testing [17].
With unit testing a function or some other part of the system is tested with regard to its implementation. Integration testing tests how different parts of the system under test works together and finally system testing ensures that the system works with respect to its architectural design [17].
2.3.1 Random testing
The idea of random testing is to generate random inputs to the system under test and then having an oracle evaluating the result [13]. Random testing is not much worse than systematic testing methods and can be a cheap way of finding errors [8]. However, an oracle is not always easily available (or is very hard to define) 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 of which being
P (no errors found) = (1 − Θ)n
For a particular use case of platooning emergency braking, the success of a test case could be determined by an oracle such as “the test case fails if and only if there exists a distance ≤ 0 between any two vehicles”.
However, with random testing it is hard to reason about how much that is actually 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 a model 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 system that is actually learned can be computed.
Learning based testing is divided into two phases, first the system under test is learned until a certain number of hypothesis automata has been learned or a fixed amount of time has passed. During the second phase the final hypothesis automata is verified using a model checker. The quality of the model checker result can be determined by estimating how well the system was learned which is done using a stochastic equivalence checker: Out of a certain number of random test cases, how often does the test result differ between the actual system and the 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 with operators 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 eventually become still”.
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].
PLTL can be used in conjunction with a model, e.g. one that is learned, to verify 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 testing with actual road travelling vehicles (which is not discussed further).
An example of an analytic analyzing of a platoon is done in [7] where a context aware retransmission scheme is used to analyze platoons of different length. The authors analyze the platoons with respect to a so called “packet reception ratio”
against the length of a transmission (called super-frame), which is proportional to the frequency of the messages. Calculations around the probability of the message being received are done for different platoon lengths and super-frame lengths. From [7] it can be noted that for high frequency messages the platoon length is severely limited and vice versa, if the probability to receive a message has to be high the message frequency must be decreased for long platoons.
However an analytic analyzing only of a platooning system might fall short as the vehicles behaviours’ might be hard to analyze analytically for any reasonable sized vehicle model, justifying a need to simulate the vehicles and the platoon.
An example of this case is done in this report.
Chapter 3
The platooning simulator
It would be infeasible to drive around in actual vehicles in order to test the platoon since this would take an enormous amount of time, would be bad for the environment and probably result in a number of crashes and injuries for the vehicles’ drivers. Therefor a simulator, KTH PlatoonSim, is needed in order to evaluate the platoon algorithm.
Building upon the basis described in Chapter 2, this chapter first describes some characteristics of KTH PlatoonSim and goes on to define a high level communication model which is added to the simulator. The communication model is then extended with a notation of packets and a simple model for packet loss. Finally two different emergency braking strategies are defined, a cooperative emergency braking protocol (CEBP) and a trivial emergency braking strategy which only uses the vehicles’ CACC components. (CACC is an abbreviation for co-operative adaptive cruise control and is an extension of adaptive cruis control or ACC.)
3.1 Introduction
In this report the KTH PlatoonSim platooning simulator is built upon and extended. It builds upon earlier work from [14]. For the purpose of the work described in this report the simulator was extended with a new communication model, 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 method to hold configuration parameters for each instance of a platoon was also added.
The simulator has the capability of simulating point mass model of a vehicle and running vehicles in a platoon of any fixed length. The simulator is one- dimensional, the vehicles can only accelerate and move forward, brake or stand still. Each vehicle is controlled by its gas and brake pedal and an ”e” button to 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 the parts of a simulated vehicle fit together.
VBW VBW VBW
VBW
VBW
VBW VBW VBW
VBW
ABS ABS VBW
VBW
ABS ABS VBW
VBW GBC VBW
BTC VBW
CACC VBW
ODOM WCOM VBW
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 corresponds to one millisecond. Different parts are run with different resolutions, e.g. every 10:th tick.
The ACC takes as input the position and velocity of the vehicle immediately in front, this data is sent as a status message from a vehicle vi to vi+1 (where i ∈ {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 not smaller 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 independently of the packet error rate for CEBP messages.
• There are options to provide output more detailed than standard, this is used for visualization.
• The type of communication: Broadcast or multi hop (i.e. packets are relayed over point-to-point links)
Each platoon vehicle has two main modes, cruising and emergency braking.
During cruising the CACC controls the vehicle, when the emergency braking is activated the CACC is deactivated and the vehicle’s braking system activates the brakes resulting in the emergency braking having complete control over the vehicle.
3.2 The Vehicle Communication Model
This section describes the communication between the vehicles in the simulated platoon i.e. the radio channels, the multiple access scheme, the modelling of the radio transmissions, the transmission algorithm and finally the message structure.
An overview of how the messages travel is seen in Figure 3.2: data from the vehicle’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 slotted multiple access scheme, and the highest priority message is sent over the radio channel 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 G5 and possible 5G implementations.
As for ITS G5 the following simplifications have been made:
• The multiple access scheme and collision detection and avoidance have been replaced with a slotted access scheme which is described below.
• CAM messages are not used. Instead status messages (only containing the vehicle’s speed and position) are sent with fixed frequency in contrast to the 1-10 Hz variable frequency of CAM messages.
• DENM messages have been substituted for custom CEBP messages and are subject to the slotted access scheme.
As for a 5G cellular network, it can be noted that 5G has not yet been specified. However, the work described in this report assumes the following of a future 5G network:
• The bandwidth of the wireless communication is assumed to be ”high enough”, 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 a slotted access scheme or a logical channel over i.e. UDP/IP where the slotted access scheme can be implemented.
VehicleStatus
RadioBlock
Vehicle 0
Vehicle 1
RadioBlock
VehicleStatus
Various parts of the vehicle read the vehicle state and create messages
RadioBlock transmits the message with highest priority and keeps the rest in a queue
CommunicationController forwards the message to all radio blocks with broadcast or a single recipient with multihop
RadioBlock makes recieved messages available
The receivers update the vehicle state
CEB
CEB cebp
cebp
cebp
cebp
position, velocity
position, velocity
RadioChannel
Figure 3.2: An overview of the communication between the vehicles, here with two messages of different types. The CEBP message is selected since its priority is higher than the vehicle status message.
It is assumed the bandwidth is large enough so that multiple 500 byte messages can be transmitted during the 1 ms simulator tick. A reasonable assumption is that a real world implementation could communicate over a 5G cellular network with a bandwidth high enough to sustain the messages being
transmitted. Even though 5G is not standardized as of the time of writing requirements listed in e.g. [19] indicate that a 5G network has high enough capacity 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 simulator with high level communication. The protocols implemented into the simulator had to be possible to use in a real world scenario, more specifically collisions in the radio traffic had to be avoided in the communication model.
The CSMA/CD scheme used by 802.11p uses a random time back off starting on the order of micro seconds when a collision is detected [1].
The challenge with back off time being in the order of micro seconds is that the platooning simulator is implemented with a granularity of 1 ms. The consequence of which is that the back off would be performed directly or during the next tick. Thus the back off would effectively be 0 ms or 1000 ms both of which would be wrong. Furthermore there are other simulators such as OMNeT and Veins for actual simulation of the communication. With the goal of this report being to test the system of systems, accurate simulation of the radio communication is out of scope.
As a platoon is fairly static it has been proposed in [7] to use a TDMA scheme as a simple alternative instead of meeting the complex requirements the 802.11p network stack requires. This is only feasible if the clock in each participating radio is synchronized with the rest of the system, something which can be done with GPS [4].
Another reason for choosing a TDMA scheme is that estimations for when a packet should have arrived are made easier since it is known when a message is due to be sent, in contrast to the 802.11p collision avoidance where the exact packet transmission times might be non-deterministic.
For the reason listed above a TDMA scheme implementing round robin is used to schedule the vehicles’ radio transmissions and every vehicle in an n vehicle platoon is allowed to transmit every n:th millisecond interval:
Let vibe 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 send status 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 radio channel is shared between the vehicles whereas the radio is tuned to a single channel, enabling multiple radio channels to be in use the same tick. Effectively each vehicle thus can have multiple radios.
Figure 3.3: Four vehicles A, B, C and D transmit their respective status message si every hundred time interval. Unused slots where the vehicle is allowed to transmit are blank whilst the remaining slots are marked by a cross (during which the vehicle is not allowed to transmit).
Two types of radio links are available, broadcast and point-to-point between adjacent vehicles. As for broadcast communication, each message is heard by every vehicle in the platoon. With multi-hop communication a message is passed from one vehicle to the next. In this case a message is passed forward or backward in the platoon and vehicles in the message’s path will overhear the message.
With a three vehicle platoon with vehicles v0, v1and v2, a message m0from v0
to v2is transmitted two times, from v0 to v1and from v1to v2 and is overheard by v1. Another message m1sent from v1to v0is only transmitted this one time and v2 has no knowledge about m1.
3.2.4 The transmission algorithm
The transmission algorithm is listed in Algorithm 1, each tick when the vehicle is allowed to transmit the message with the highest priority is removed from the transmission 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 := f irst(Q)
remove m from Q transmit m end if
3.2.5 Estimating an upper bound for the timeout values
in CEBP
This section derives equations to calculate when any vehicle in the platoon should expect 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 platoon and that CEBP messages are sent as soon as possible.
From equation 3.1 it follows that any vehicle with index i is allowed to transmit at any time i = i + k · n where k ≥ 0 denotes the TDMA cycle. This gives 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 Visends an E-brake request at time 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 ACK at 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 time t = n(k + 1) − a + (a − 1)(n − 1) which results in that Vi should expect to have received the ACK at time t = n(k + 1) + (a − 1)(n − 1) − a + 1. Substituting a we 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 the last vehicle: If the lead vehicle V0 transmits an E-brake request at time t0≡ 0 mod n to the last vehicle Vn−1 it is received by V1 at time t0+ 1. Note that vehicle V1is allowed to forward this message the same tick and the corresponding holds for the rest of the vehicles when the E-brake request is forwarded. Since the 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 should be received by V0at 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. The probability of a message being lost depends on two numbers, the base packet error rate b and the distance between the sender and receiver. Messages can be lost independently by two different receivers.
A linear model b + a · d was chosen for the calculation of the packet error rate where b is the base packet error rate, a is the attenuation factor and d corresponds to the distance between the sender and receiver.
Measurements done on a public Swedish motorway yields b = 3, 67% for adjacent vehicles and linear regression gives a = 18, 6 [2]. Thus the packet loss model 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 vehicles in the platoon. Note that for d ≥ 6 (e.g. a message from the lead vehicle with i = 0 to the eight vehicle with i = 7) every packet is lost to the receiver. (An example of a situation where a message is dropped is shown in Figure 3.4 which highlights that a single message can be received by some vehicles and lost to other vehicles.)
This model was developed together with Carl Bergenhem in [2] as a ”better than nothing” way of enabling packet loss into the communication where the likelihood of a message being lost is increased with the distance between the sender and receiver. Accurate simulation of the radio waves is out of scope of this report.
Figure 3.4: An example where a broadcast message sent by vehicle 0 is received by vehicles 1 and 2 whilst lost to vehicle 3.
3.4 Messages
This section describes the abstract messages that are transmitted. The messages always 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 message priority: 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.isM ultihop = true 0 otherwise
3.5 The emergency braking strategies
This section describes the three emergency braking methods: A cooperative emergency braking protocol (CEBP), a trivial CACC emergency brake and a combination of both.
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 the algorithm is to bring a platoon to a complete stop in a more efficient manner compared to only using the vehicles’ CACC components to actuate the braking.
Figure 3.5 describes the same protocol in a diagram. In essence the protocol ensures that no vehicle starts braking before its immediately succeeding vehicle has acknowledged that it has started braking, unless the immediately succeeding vehicle fails to receive the emergency braking request, in which case the vehicle starts braking when a timeout threshold is reached.
Algorithm 2 Pseudo code describing CEBP
1: if Ego Vehicle Vi wants to e-brake then
2: send “E-brake request” to last vehicle VN-1 3: end if
4: if ”E-Brake directly” is received by Ego Vehicle Vi then
5: send “E-brake request” to last vehicle VN-1 6: end if
7: if Ego Vehicle Vi (has sent “E-brake request” command) or (overheard
“E-brake request” from Vj) then
8: prepare brake system
9: Start Ti
10: end if
11: if “E-brake request” is received by Ego Vehicle Vi from a preceding vehicle Vj, where j ∈{0..i-1} then
12: Ego Vehicle Vi actuate e-brake strategy
13: send “E-brake ACK” to the next preceding vehicle Vi-1 14: end if
15: if “E-brake ACK” is received by Ego Vehicle Vifrom next succeeding vehicle Vi+1then
16: Ego Vehicle Vi actuate e-brake strategy
17: Stop Ti
18: if i > 0 and has not already sent an “E-brake ACK” to preceding then
19: send “E-brake ACK” to the next preceding vehicle Vi-1 20: end if
21: send “E-brake ACK” to the next preceding vehicle Vi-1 22: end if
23: if Ti expires then
24: Ego Vehicle Vi actuate e-brake strategy
25: 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 if
28: if Ti is started then
29: decrease Ti 30: end if
Figure 3.5: A presentation of CEBP using automata.
3.5.2 CACC emergency brake
CACC emergency brake is an ad hoc method of doing emergency brake: When the emergency brake is activated in the lead vehicle its CACC actuates maximum brake pedal. The next scheduled status message that is sent to the immediately succeeding vehicle is updated to tell the immediately succeeding vehicle that it also should actuate CACC emergency brake. Since CACC status messages are transmitted every 100 ms it may take several hundred milliseconds for the last vehicle 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 state CEBP and CACC emergency brake is combined: When the emergency brake is activated in the lead vehicle it initiates CEBP and also activates its CACC emergency brake. This leads to the lead vehicle braking earlier than with only CEBP.
Chapter 4
Methods
Building upon the simulator described in Chapter 3 this chapter describes a binary search method, then a random testing tool for KTH PlatoonSim to test the hypothesis from Chapter 1. Finally a tool to visualize the platoons are shown.
Two different approaches were considered, an approach using learning based testing and one approach using random testing. Early attempts were made with learning based testing but the learned models were too large for the model checker and so the learning based testing approach was deemed to take too much computing time to be feasible. In contrast random testing was only limited to the simulation execution time.
4.1 The binary search method
A binary search method, described in Algorithm 3 is constructed to find a platoon with no crashes, where a crash is defined as “the inter-vehicle distance between any 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 vehicles is 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 crashes in any of the test cases. This together with the simulator forms a Monte Carlo algorithm to find the minimum time headway fast.
As described earlier there are three emergency braking strategies present in the simulator:
• CACC emergency brake
• CEBP
• CACC + CEBP, the combination of both
A test wrapper is written which bridges input and output between testing tool and the platooning simulator enabling the platoon itself to be tested.
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 beginning the values have to be estimated. Note that hwmax should be selected in an educated 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 := 0
while |hw − hwprev| > tolerance or there are crashes do hw = (hwmax+ hwmin)/2
Run tests with the headway hw if there are crashes then
hwmin:= hw else
hwmax:= hw end if
hwprev:= hw end while
Output: The found time headway hw.
4.2 The random testing tool
The random testing tool generates a test suite of 10 000 random test cases and varies the inter-vehicle time gap using the binary search method until the minimal safe time gap is found within a precision of 0,01 seconds. (The reasoning to use 104 test cases and not 103 or 105 test cases is rather arbitrary. The number of test cases ought to be large as to simulate a larger driving distance but 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 immediate in front (where a crash is defined as the inter-vehicle distance ≤ 0). This model checker however is hard coded in the implementation and is not expressed with a high level logical language such as PLTL or even propositional logic.
KTH PlatoonSim is controlled by sentences of commands from a system specific 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
Emergency braking strategy Suffix
CEBP 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 Meaning
a7 +1,4 m/ss Actuate 70 % gas pedal b4 -1,2 m/s2 Actuate 40 % brake pedal
0 0 m/s2 The no-op command, do nothing e -2,2 m/s2 Activate emergency braking with CEBP bE -2,2 m/s2 Activate CACC emergency brake cc -2,2 m/s2 Activate the combined emergency brake Table 4.2: The acceleration values for the simulator symbols used as well as their meaning. Note that all commands a10..a1 and b10..b1 are implemented but not used.
emergency braking) and cc (activate the combination of CEBP and CACC emergency braking).
Each command is enacted by the lead vehicle for a period of 5 seconds before switching to the next one in the sentence. The following vehicles uses their CACC algorithms to follow in the platoon. An arbitrary example sentence for the simulator is a3,a7,a10,0,0,b4,b4 which would correspond to a slow but increasing acceleration, followed by a released gas pedal before braking.
For the particular work being done in this report the commands used are a7 and b4. As seen in Table 4.2 these commands corresponds to reasonable acceleration and braking speeds.
Each test case is generated as a random string of the commands followed by an emergency braking suffix, which leads to that the lead vehicle is either in an accelerating mode or a braking mode. Experience with the simulator shows that this type of gas-and-brake driving is challenging for the CACC algorithm and is used to provoke the system into a bad state before performing the emergency brake. The number of symbols is limited to these two to keep the space of possible test cases small, 220≈ 106compared 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 emergency braking is performed with 100 % brake pedal (which is b10 for the simulator).
Each random string consists of 20 symbols, thus each test case corresponds to 100 seconds of driving and each test suite corresponds to 278 hours of continuous driving.
Using random combinations of a7 and b4 as described above, examples of possible test cases are as follows (except for the emergency braking suffixes):
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 a bit and then brake”, since random testing is used the platoon behaviour is much more random. For example: with test sequence 1, the platoon “accelerates for 5 seconds, 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 understandable for a human. In particular two things prevent an intuitive understanding of the behaviour:
• A series of numbers are returned for the positions and velocities of the vehicles and it is hard to get an overview of a moving system by reading samples of the state.
• The simulator is sampled every five seconds which leaves a rather large gap where emergent properties occur which is hard to observe from position and speed samples alone.
For these reasons a visualization tool was developed, see in Figure 4.1. Using this tool a test case can be analyzed and stepped through with a resolution of 15 ms. A number of parameters can be configured: the number of vehicles, the time headway, the command sequence, whether packet loss is enabled and if there 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 the second vehicle having a much higher velocity than the first during the braking.
Figure 4.1: The platoon visualization tool. The values shown are lateral position, velocity and acceleration.
Figure 4.2: The second vehicle have a much higher velocity than the first during the braking which results in a crash.
Chapter 5
Testing results
This chapter describes results obtained from running the random testing tool described in Chapter 4 in four different configurations: with two different communication strategies, broadcast and multi hop, and with or without the packet loss model.
5.1 Introduction
This section overviews the results from the testing, the minimal safe time headways (defined below) and comparisons between the different emergency braking strategies with different lengths of the platoon and with or without the linear packet loss model.
There are two ways of describing the distance between two vehicles in a platooning system: the distance and the time gap, the time gap obviously varies with the vehicles’ speeds. Inter-vehicle time gap is used in this report and thus the minimal safe time headway is defined as the minimal inter-vehicle time gap t such that if the vehicles all keep the time gap t there are no crashes. (Remember from Chapter 4 that a crash is defined as the inter-vehicle distance is less than or equal to 0.)
There are four different communication scenarios tested by using different communication 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 with an improvement of 3.3 % over CACC emergency brake. For multi hop communi- cation and packet loss CEBP performs the worst and the combination of both strategies performs the best.
With no packet loss CACC emergency brake performs on average slightly better than CEBP and the combination. However, it is worth noting that this difference is on the order of 1 %.
The graphs and tables are presented in the following order: first graphs for
Broadcast communication Multi hop communication Packet loss CEBP + CACC performs
the best
CEBP + CACC performs the best
No packet loss CACC performs slightly better 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 followed by tables with comparisons. Thereafter the corresponding graphs and tables are presented 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 in Table 5.1. Then measurements and tests with the packet loss model enabled are shown (in Figures 5.1 and 5.2 and Tables 5.2 through 5.4) and finally the measurements and results with no packet loss model are shown (in Figures 5.3 and 5.4 and Tables 5.5 through 5.7).
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
Minimum time headway with 0 crashes
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 CACC though the combination is not far behind. However for this particular test run there is a sweet spot at 5 vehicles which balances the number of vehicles against the 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
Minimum time headway with 0 crashes
Number of vehicles
Multihop, packet loss
CEBP CACC CEBP + CACC
Figure 5.2: Multi hop communication with packet loss
With multi hop communication the probability of a single packet being dropped is smaller since the distance is only 1 vehicle. Here an advantage can be seen for the combination of CEBP and CACC with the sweet spot being a platoon length of 4 vehicles.
Comparison Mean improvement Median improvement
CEBP 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 broadcast communication and packet loss. The combination of CEBP and CACC performs slightly better in the average case.
Comparison Mean improvement Median improvement
CEBP 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 hop communication and packet loss. It can be noted that in this case solely using CEBP might perform worse and adding in CACC as well results in a better braking strategy with regards to the time headway.
N Broadcast Multi hop
2 -0,021 -0,141
3 0,141 0,088
4 0,146 0,293
5 0,017 0,135
6 0,056 0,014
7 -0,004 -0,079
Table 5.4: The difference in seconds between CEBP+CACC and CACC for different platoon lengths and communication methods, using the linear model for packet loss. This show that the choice of emergency braking strategy is important, for example 4 vehicles with multi hop communication would correspond to a difference of 7 meters with the platoon driving at 90 km/h.
0 0,2 0,4 0,6 0,8 1 1,2 1,4
0 1 2 3 4 5 6 7 8
Minimum time headway with 0 crashes
Number of vehicles
Broadcast, no packet loss
CEBP CACC CEBP + CACC
Figure 5.3: Broadcast communication with no packet loss. There is barely any difference 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
Minimum time headway with 0 crashes
Number of vehicles
Multihop, no packet loss
CEBP CACC CEBP + CACC
Figure 5.4: Multi hop communication with no packet loss. There is barely any difference between the braking strategies.
With perfect communication, i.e. no packet loss, the difference is small
between the braking methods. Should this always be the case, probably the simplest method ought to be chosen.
Comparison Mean improvement Median improvement
CEBP 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 broadcast communication and no packet loss. In this case solely using CACC would be the best choice.
Comparison Mean improvement Median improvement
CEBP 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 hop communication and no packet loss. Also in this case solely CACC would be the best choice.
N Broadcast Multi hop
2 -0,013 0,027
3 0,013 0,038
4 0,028 0,003
5 0,042 0,012
6 0 -0,003
7 -0,020 -0,025
Table 5.7: The difference in seconds between CACC and CEBP for different platoon lengths and communication methods, with no packet loss. The differences correspond to less than a meter of distance headway at 90 km/h.
Chapter 6
Discussion and conclusions
This chapter discusses the results from Chapter 5: first the testing method is evaluated and then the test results themselves are discussed. In the end possible future work is reviewed.
6.1 Evaluation of the testing method
The approach described in this report can partly be used to perform requirements testing 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 evaluate statement such as “is there a crash in the test result?”. With some background in software testing the tooling is easy to construct and if a large enough number of test cases are generated and executed guarantees such as “when driving in the worst possible way there is a crash more seldom than D km” for some driven distance D.
However when driving in a more general manner, for example when all symbols a1 . . . a10 and b1 . . . b10 are used the space of possible test cases becomes very large very quickly which effectively prevents any reasonable test coverage. For these 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 and available computing power is a limiting factor.
On the subject of test coverage there is no way to know how well the platoon is actually tested besides the above mentioned more than D km before a crash occurs.
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 lane switching). An engine model could affect the simulation since it would apply engine braking when there is no acceleration. The CACC algorithm used is also a primitive one since there is no “look ahead” to vehicles in front of the immediately preceding vehicle, i.e. any vehicle only has information regarding the one immediately preceding. Furthermore the communication models are on
a high level with no simulation of how the radio waves and their message packets would behave in an actual real-world scenario. Note, however, that there is a wheel model including slippage for ABS braking.
To conclude, random testing with the binary search method could be used as a quick pointer before more extensive verification and testing is done which is needed for safety critical applications.
6.2 Discussion of the results
From [16] it can be concluded that a coordinated braking strategy which is limited by the slowest breaking vehicle is needed for safe platoon braking. This is related to behaviour seen with KTH PlatoonSim, in some cases there exists a vehicle much faster than the immediately preceding one. This often results in crashes since the applied deceleration force is not enough to stop the vehicle in time to avoid crashes. Since the kinetic energy Ek =mv22 the use case cannot directly be translated to a faster vehicle but the behaviour of needing too much energy 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 considered over CACC: The result is that CEBP which starts braking from the end of the platoon enables a lower time headway than CACC emergency braking from the beginning of the platoon. It can be argued that this is the scenario which corresponds to a hypothetical real world platoon since there is packet loss in the real world and emerging 5G applications would enable broadcast communication.
However, the necessity for starting braking from the end of the platoon seems to be smaller when the communication is perfect as seen in the simulation with no packet loss.
One emerging property that can be observed using the visualization tool is that it is quite easy to make the vehicles in the platoon end up in a state where one vehicle is braking whilst the immediately succeeding vehicle is accelerating to decrease the distance between the vehicles. Often this results in a crash and it is quite possible that it is this property that requires the time headway to be as large as it is. An example is seen in Figure 6.1.
To summarize it seems that the combination of CEBP and CACC would be 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 and extended, which yields some reasonable vehicle dynamics in the simulated system.
V0 V1 V2
Traveling direction
V0 V1 V2
V0 V1 V2
V0 V1 V2
2 1
3
4
V0 V1 V2
5
Figure 6.1: An example of an impending collision. In step 1 the vehicles travel at some steady state and V0 begins to accelerate. In step 2 V1 is too far behind V0 so it accelerates to lessen the gap. In step 3 V1 has returned to its desired headway with respect to V0 but V2 begins to accelerate. The bad thing happens in step 4 where V0 performs some (emergency) brake and thus V1 (which travels with the same speed and acceleration as V0) also brakes. However, V2 is still in an accelerating state or travels much faster than V1 and does not have enough braking 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 and to construct more detailed LTL formulas for the test case oracle. An example of a 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 greater than zero always results in the coming to a stop”.
The communication model used in this report is far from the standardized 802.11p and provide no modelling at all of radio waves or how they interact with
the environment. The testing could be replicated in a simulator where this is provided.
Second the vehicle model currently in use has limitations such as lack of an engine model and the weight of each vehicle is the same and fixed. The simulator could be extended to incorporate elements such as these. Furthermore the simulator is one-dimensional and could be extended to support lane changing and turning.
Finally more work could be done on the verification of the protocols: For example the driving requirement could be divided into two phases, one cruising phase were the vehicles must never be too close nor too far from each other and an emergency braking phase were the requirements are relaxed into no crashes.
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 Physical Layer (PHY) Specifications”. In: Retrived from http://standards. ieee.
org/about/get/802/802.11. html (2012).
[2] Carl Bergenhem, Karl Meinke, and Fabian Str¨om. “Quantitative safety analysis 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: Proceedings of the 19th ITS World Congress, Oct 22-26, Vienna, Austria (2012). 2012.
[4] Katrin Bilstrup. A survey regarding wireless communication standards intended for a high-speed vehicle environment. 2007.
[5] Katrin Bilstrup et al. “On the ability of the 802.11 p MAC method and 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. “Performance comparison of a platooning application using the IEEE 802.11 p MAC on 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 B¨ohm et al. “Context-aware retransmission scheme for increased reliability in platooning applications”. In: International Workshop on Communication 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 ().
[11] EN ETSI. “302 663 (V1. 2.1)(11-2012):” Intelligent Transport Systems (ITS)”. In: Access layer specification for Intelligent Transport Systems operating in the 5 ().
[12] Michael Fisher. An introduction to practical formal methods using temporal logic. 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 testing tool 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 Close Following 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 truck platooning. 2017.
[19] Afif Osseiran et al. “Scenarios for 5G mobile and wireless communications:
the vision of the METIS project”. In: IEEE Communications Magazine 52.5 (2014), pp. 26–35.
[20] Umit Ozguner, Tankut Acarman, and Keith Redmill. Autonomous ground vehicles. Artech House, 2011.
[21] Kimihiko Rencheng Zheng et al. “Study on Emergency-Avoidance Braking for the Automatic Platooning of Trucks”. eng. In: Intelligent Transportation Systems, IEEE Transactions on 15.4 (2014), pp. 1748–1757. issn: 1524- 9050.
[22] Katrin Sj¨oberg. “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 for energy saving”. In: IEEE International Conference on Intelligent Robots and Systems. 2011, pp. 4109–4114. isbn: 9781612844541.
TRITA -EECS-EX-2019:73