Scholarly article on topic 'Designing fail-safe and traffic efficient 802.11p-based rear-end collision avoidance'

Designing fail-safe and traffic efficient 802.11p-based rear-end collision avoidance Academic research paper on "Electrical engineering, electronic engineering, information engineering"

CC BY
0
0
Share paper
Keywords
{RECA / FCW / "Collision avoidance" / "Wireless communication"}

Abstract of research paper on Electrical engineering, electronic engineering, information engineering, author of scientific article — Natalya An, Jens Mittag, Hannes Hartenstein

Abstract An essential, but nevertheless often neglected, objective for the design of safety-critical IEEE 802.11p-based application is: fail-safety. A fail-safe application is an application that incorporates features that automatically counteract the effect of anticipated sources of failure. In the context of a rear-end collision avoidance application two main possible sources of failure exist: an unpredictable human behavior and unreliable communication. This paper presents mechanisms that, when integrated into the design of rear-end collision avoidance application, counteract these failure cases and thus ensure fail-safety. However, fail-safety comes at a cost: either large inter-vehicle distances have to be kept to ensure that all drivers have enough time to react or the application has to take over vehicle control to allow smaller inter-vehicle distances and thus higher traffic efficiency. In this paper we analyze this tradeoff and quantify what part of drivers’ population has to be deprived of vehicle control in order to achieve acceptable traffic efficiency when deploying IEEE 802.11p-based rear-end collision avoidance application.

Academic research paper on topic "Designing fail-safe and traffic efficient 802.11p-based rear-end collision avoidance"

Contents lists available at ScienceDirect

Ad Hoc Networks

journal homepage: www.elsevier.com/locate/adhoc

Designing fail-safe and traffic efficient 802.11p-based rear-end collision avoidance

CrossMark

Natalya An, Jens Mittag*, Hannes Hartenstein

Institute of Telematics & Steinbuch Centre for Computing, Karlsruhe Institute of Technology, Germany

ARTICLE INFO

Article history: Received 2 March 2015 Revised 23 June 2015 Accepted 14 August 2015 Available online 22 August 2015

Keywords:

Collision avoidance Wireless communication

ABSTRACT

An essential, but nevertheless often neglected, objective for the design of safety-critical IEEE 802.11p-based application is: fail-safety. A fail-safe application is an application that incorporates features that automatically counteract the effect of anticipated sources of failure. In the context of a rear-end collision avoidance application two main possible sources of failure exist: an unpredictable human behavior and unreliable communication. This paper presents mechanisms that, when integrated into the design of rear-end collision avoidance application, counteract these failure cases and thus ensure fail-safety. However, fail-safety comes at a cost: either large inter-vehicle distances have to be kept to ensure that all drivers have enough time to react or the application has to take over vehicle control to allow smaller inter-vehicle distances and thus higher traffic efficiency. In this paper we analyze this tradeoff and quantify what part of drivers' population has to be deprived of vehicle control in order to achieve acceptable traffic efficiency when deploying IEEE 802.11p-based rear-end collision avoidance application.

© 2015 The Authors. Published by Elsevier B.V. This is an open access article under the CC BY license (http://creativecommons.org/licenses/by/4.0/).

1. Introduction

The main motivation behind vehicular communication research is to explore the possibility of IEEE 802.11p communication to contribute to safer and more efficient road traffic. Various applications are envisioned to assist the driver in different traffic situations, e.g., on intersection crossing [1] or in the traffic flow [2]. Applications are anticipated to notify the driver, e.g., as in forward collision warning or even take over the vehicle control, e.g., as in rear-end collision avoidance (RECA).

In order to determine whether a particular IEEE 802.11p-based application is feasible, its application logic has to be carefully and clearly designed. One of the most important design features for virtually any system, but especially for safety-critical applications is fail-safety. According to the

* Corresponding author. Tel.: +4972160845783. E-mail address: jens.mittag@gmail.com (J. Mittag).

definition of Merriam-Webster dictionary, we consider a fail-safe application to be an application "that incorporates features for automatically counteracting the effect of an anticipated possible source of failure". At the same time, the design of a driver assistance application has to pursue an efficiency objective, i.e. it should yield a reasonable traffic flow. Obviously, this is a trade-off situation as traffic safety and traffic efficiency sometimes have contradicting requirements.

Driver assistance applications that are based on in-vehicle sensors, like cameras or radars, are being also researched and designed e.g., [3], and even standardized, e.g., ISO 15623 [4]. In-vehicle sensors have their limitations, e.g., sensitivity to weather conditions [5] and to interference [6]. Furthermore, many of these sensor-based applications rely on the driver to take actions, which makes the effectiveness of these systems highly dependent on the adequate response of the drivers. As recent tendencies move towards automated driving, it is now possible to extend fail-safe features beyond the pure

http://dx.doi.org/10.1016/j.adhoc.2015.08.006

1570-8705/© 2015 The Authors. Published by Elsevier B.V. This is an open access article under the CC BY license (http://creativecommons.org/licenses/by/4.0/).

reliance on the driver. In this context, the intention of this work is not to substitute sensor-based applications but to explore new opportunities enabled by communication and potential synergy approaches [5].

In this paper we design an IEEE 802.11p-based RECA application following a fail-safe objective. We focus on two main sources of failure that can deteriorate fail-safety: unpredictable driver behavior and an unreliable wireless communication. To counteract the aforementioned sources of failure the designed application assumes (1) worst case situation changes during the packet inter-reception time and (2) automatic braking in case the driver fails to adequately react to the warning. The application either imposes large inter-vehicle distances to ensure that all drivers have enough time to react, or it takes over vehicle control to allow smaller inter-vehicle distances and thus higher traffic efficiency. We analyze this tradeoff and quantify what part of driver's population has to be deprived of vehicle control in order to achieve acceptable traffic flows. We compare the resulting traffic densities to the highway level of services [7] and with Germany's road traffic regulations. We further evaluate the feasibility of IEEE 802.11p communication to support the failsafe rear-end collision avoidance application under resulting traffic densities by looking at the resulting channel loads.

The paper is structured as follows: Section 2 describes the related work on existing rear-end collision avoidance applications. In Section 3, we first outline made assumptions and then the design of a fail-safe rear-end collision avoidance application. In Section 4, we evaluate resulting traffic efficiency and evaluate the corresponding IEEE 802.11p communication channel load. Section 5 concludes the paper.

2. Related work

Several driver-assistance applications address or are related to rear-end collisions in one degree or another. Those are: Adaptive Cruise Control (ACC), Platooning, Forward Collision Warning (FCW), Rear-End Collision Avoidance (RECA) and Emergency Electronic Brake Lights (EEBL). An ACC is an application that automatically adjusts vehicle's speed to maintain a safe distance to a vehicle ahead, thus relieving a driver from frequent alternating between braking and acceleration. A Platooning is an approach to group moving vehicles in order to decrease the distance between them, thus increasing the road capacity. As opposite to optimizing driving comfort or traffic efficiency, an FCW and an RECA applications aim to improve traffic safety by mitigating or avoiding rear-end collisions. A FCW provides a warning to a driver in case of a potential rear-end collision, and a RECA application additionally includes an automatic braking in case a driver did not respond sufficiently. The automatic braking of RECA application is typically preceded by a warning, as in FCW. Obviously, the ACC and Platooning are susceptible to rear-end collisions and, as a result, are often combined with FCW or RECA. All these applications share similar hardware equipment, i.e. a sensor to measure the distance to the vehicle ahead, and a global navigation satellite system (GNSS) receiver to obtain own location data. The first-generation radar-based ACC, FCW and RECA applications are already sold under various trade names and variations by different automotive manufactures. An EEBL application broadcasts in-

formation in case THE own vehicle performs a sudden braking. The reception of such information, if appropriate, triggers actions from FCW or RECA applications at the receiving vehicles. The relationship between these applications are described in several papers, e.g. by [8-10].

The predecessor of an ACC is a simple Cruise Control system which was first fitted to vehicles as early as in 1900 [11]. The Cruise Control system is intended for the use during long-time driving on roads with sparse traffic density. While Cruise Control provides additional comfort to the driver by maintaining a constant speed [12], Adaptive Cruise Control relies on in-vehicle sensors to recognize an upstream moving vehicle and to derive the distance to that vehicle. ACC algorithms adjust the speed of the own vehicle automatically in order to maintain a safe time headway and/or a small relative speed, thus making human intervention unnecessary [13]. Therefore, characteristics of the human driver are relatively unimportant for the ACC.

The standard ISO 15622 [14] describes basic functionality and performance requirements ofan Adaptive Cruise Control. According to Ref. [14], "the goal of ACC is a partial automation of the longitudinal vehicle control and the reduction of the workload of the driver with the aim of supporting and relieving the driver in a convenient manner". The standard further describes two types of ACC, type 1 and type 2, with the difference that ACC type 2 applies "active brake intervention with a clutch pedal". Yet, the deceleration is limited (shall not exceed 3.5 m/s2 averaged over 2 s) and might not be enough to avoid a rear-end collision. As conventional ACC is not intended to operate at lower speeds, a Full Speed Range Adaptive Cruise Control (FSRA), standardized as ISO 22179 [15] was developed to function at all vehicle speeds, e.g. also in congested traffic conditions.

ACC systems mostly rely on a radar or a laser sensors, with some systems utilizing a lidar or even a stereo camera [12,13]. A Cooperative Adaptive Cruise Control (CACC) as in [16-22], is an extension of the ACC where additional information, such as an acceleration of the leading vehicle is gained via wireless communication. The major benefit of CACC over ACC is a string stability. Without string stability the oscillations which are introduced by braking and accelerating vehicles, can be amplified and eventually lead to traffic jams or even to rear-end collisions.

Platooning has been a topic of research for many decades as well. Standard SAE J 2945/6, which is being developed since January 2015, is to define the differences between Platooning and CACC, as well as the necessary communication data exchange which is required to coordinate vehicle maneuvers. With Platooning, vehicles are thought to be grouped into platoons in order to increase the road's capacity and the driver's comfort through automation. Required longitudinal vehicle control algorithms, that are necessary to control spacing between vehicles and their speed, have been published starting 1970's, see [23-25]. First demonstrations took place in 1990's and proved the technical feasibility of automated driving with Platooning [26-28]. Platooning typically requires installation of magnetic markers on the road to facilitate vehicle tracking and to guide the steering, whereas radars are utilized to track the distance to the following and leading vehicles [27]. Additionally, the usage of wireless communication to control platoons has been increasing

with the progressing development of communication itself [27,28].

The ACC and Platooning systems, although include automated braking to reduce the need for the driver intervention, are only designed to increase driver's comfort and convenience, but not to prevent collisions, especially those that result due to a sudden braking. For an active collision prevention a system that relies on human follow-up actions, like Forward Collision Warning, or a system with automatic collision avoidance features, like Rear-End Collision Avoidance, is required [29,30].

A Forward Collision Warning is a precrash safety system that warns a driver if there is a possibility of a collision with a preceding vehicle due to either too high relative speed or too small inter-vehicle distance [31]. Hence, the safety benefit of the FCW system depends on the adequate response of the driver, which depends on driver's reaction behavior, reaction time and braking intensity. The first document containing preliminary guidelines for an FCW system has been published by SAE International in 1997 [8]. Later, in 2002 and 2013, the ISO published an ISO 15623 standard [4] describing an FCW system.

The SAE paper defines two types of warnings: the first warning is addressing an inattentive driver situation and the second warning is addressing a following-too-closely driving situation. A warning distance is calculated and compared with the distance to the vehicle in front, and if exceeded, the driver is warned. A limited automated braking is utilized as a warning, rather than as a rear-end collision avoidance feature. Additionally, a "push-back" accelerator pedal warning is foreseen, that "resists the force placed by the driver on the accelerator pedal". The "push-back" accelerator pedal warning is also intended to only inform the driver of following too closely to the vehicle in front, and does not prevent the driver from overriding the "push-back".

The standard ISO 15623 [4] describes performance requirements and test procedures for an FCW system called a Forward Vehicle Collision Warning System (FVCWS). It is based on a radar technology and is designed to "inform the driver of the need to take action in order to avoid or reduce the severity of a possible imminent rear-end collision". The warnings should be provided in a timely manner, so that drivers avoid most common rear-end crashes by applying brakes only, hence, the FVCWS do not overtake vehicle control to mitigate the crash. Although optional warning braking is foreseen, it should last less than 1 s and should not result in a speed reduction exceeding 2 m/s, thus not necessarily serving as a collision avoidance feature.

A Rear-End Collision Avoidance (RECA) application, also called Forward Collision Avoidance (FCA) or Automatic Emergency Braking System (AEBS) [12], is an advanced version of the FCW system with additional automatic braking capability in case the driver fails to respond to the warning. The ISO Standard 22839 [10] describes a Forward Vehicle Collision Mitigation System (FVCMS) which is an "extension" of ISO 15623 [4]. The FVCMS automatically brakes to reduce the relative speed if the likelihood of a rear-end collision is assessed high. The automatic braking is preceded by a warning, which is provided in accordance with ISO 15623 [4]. The main functionality, general operational limits, as well as performance and validation requirements, are outlined in ISO 22839, al-

though implementation details are left for individual manufactures. The average deceleration should not exceed 4.0 m/s2 when a FVCMS first initiated, and can increase up to 6.0 m/s2 (averaged over 1 s).

Similarly, the EU Regulation No. 347/2012 [32] specifies the requirements and testing procedures for advanced emergency braking systems that detect a rear-end collision possibility. The advanced emergency braking systems shall warn the driver, and if the driver takes no action, automatic braking is applied. Some papers suggest that an automated braking should be "a last resort" and a rear-end collision avoidance via steering, i.e. a lane changing, should be preferred [33].

A communication-based application envisioned to address rear-end collisions is called an Emergency Electronic Brake Light (EEBL), or an Emergency Warning Message (EWM): a vehicle is broadcasting a self-generated EEBL event information to warn neighboring vehicles, cf. [34] and [35]. The EEBL application is envisioned to support not only the direct and close neighbors of the broadcasting vehicle, but also the vehicles to whom the line-of-sight is obstructed, by e.g., another vehicle or weather conditions. If a vehicle receives an EEBL message from a vehicle in front, the FCW or RECA applications shall be activated.

3. Application design

3.1. Assumptions and challenges

We assume that every vehicle possesses its current status information such as information on its ID, speed, direction, position, acceleration, and so on. This information comes either from in-vehicle sensors or over satellite navigation system and is assumed to be error-free. Mechanisms that improve the accuracy of this information are not the focus of this paper. Every vehicle has a radio transceiver and periodically broadcasts update messages with own status information in order to allow the establishment of a mutual awareness. The RECA application requires reception of at least one message from a vehicle in front and in the same lane to be activated. Based on the mutual awareness and a predefined RECA application logic, the driver is assisted with warnings and vehicle control is taken over in case the driver does not react in time. the In following we focus on the application logic itself and leave hardware requirements or how a warning should be presented to a driver out of the scope of this paper. We assume scenarios with only passenger cars with a typical vehicle length of 5.5 m [7].

The RECA application is fail-safe if it incorporates safety features to counteract possible sources of failure. Two main challenges, or sources of failure exist: (1) an unpredictable driver behavior, and (2) an unreliable communication. Though our RECA application assumes an obedient driver who responds to a warning by deceleration, it does not know the drivers reaction time and his applied braking intensity. These driver behavior characteristics differ for each driver and might even vary from one situation to another. The application logic has to account for that in order to be fail-safe. It also needs to possess an up-to-date awareness picture in order to decide which action to perform. The unreliability of wireless communication makes it impossible to know exactly when a next update message will be received.

tabtv Hictanrn H.

Warning Distance Dw

Automatic Braking DAE

Fig. 1. The typical scenario for rear-end collision avoidance application. FV - following vehicle, LV - leading vehicle.

Addressing unpredictable driver behavior

Multiple works exist that analyze driver behavior characteristics like reaction time and braking intensity [3,36]. Mainly a controlled measurement of a limited driver population for a reaction to a typical rear-end collision warning is performed. The information is available in the form of either mean values for reaction time and braking intensity or presented as a distribution with a mean and a variance. According to [3] driver's reaction time can be modeled with a lognormal distribution with mean = 1.3 s and deviation = 0.74 s and braking intensity with a truncated Gaussian distribution with mean = -0.6g, deviation = 0.1 g, truncated by max = -0.8g and min - 0.3 g, where g is equivalent to ^ 9.8 m/s2. No correlation between braking intensity and reaction time values is typically assumed.

If application gives a warning considering the reaction time and braking intensity of the average driver (mean values), all drivers that are "worse" than the average driver would not be able to react adequately, i.e., application will not be fail-safe. Therefore, in order to be fail-safe, the application has to either give a warning accounting for the "worst driver" or integrate automatic braking for those drivers that fail to respond to a warning.

Addressing unreliable communication

One option to ensure fail-safety in spite of uncertainty in between packet receptions is to assume a worst case situation change. In the case of RECA this means assuming maximum physically possible braking of the leading vehicle right after the last message was received. Accounting for such improbable scenario might seem excessive, but as it is possible, it has to be considered to ensure fail-safety.

The worst case situation change assumptions are as follows: (1) if lead vehicle is stopped, the worst case assumption is that it is still at stop. No assumption is made that vehicle drives backwards; (2) if lead vehicle is moving at constant speed, the worst case assumption is that lead vehicle started deceleration with maximum physically possible deceleration; (3) if lead vehicle is decelerating, the worst case assumption is that lead vehicle's deceleration has changed to a maximum physically possible deceleration.

Resulting application logic

When referring to a rear-end collision avoidance application or simply an application, we refer to an application running on the FV.

Application's logic is based on the layout presented in [4] and [2] but is refined for fail-safety objective. Fig. 1 illus-

trates a typical rear-end collision application scenario. Active application calculates two distances, a warning distance DW and an automatic braking distance DAB. These distances separate three possible states of the application: "no warn", "warn" and "brake" states. Application presents a warning to a driver of a following vehicle (FV) if he is approaching a leading vehicle (LV) too fast, in other words, once inter-vehicle distance (IVD) between two vehicles is equal to or less than a warning distance. The warning distance is calculated in a way that allows the driver of the FV to react by deceleration and come to the same speed as the LV at latest safety distance DS away from the LV. If the driver fails to adequately respond to a warning and the IVD decreases further below the automatic braking distance: automatic braking is started. Automatic braking distance is calculated such that it is sufficient to bring the FV to the same speed as the LV with some desired braking intensity, at latest some safety distance DS away from the LV. Hence, both distances DW and DAB can change over time, depending on the behavior of the LV and FV.

The matching flowchart of the rear-end collision avoidance application is shown in Fig. 2. Based on the input of own information and information received from the LV application determines inter-vehicle distance and performs calculation of warning and automatic braking distances. During the packet inter-reception time application estimates the speed and position of the LV with a worst case assumption. Depending on DW and DAB, as well as on the current inter-vehicle distance corresponding application's state is set. Such calculation happens in a periodic manner, but can also be triggered upon reception of a new packet from the LV.

An example of this life-cycle is shown in Fig. 3 which compares the internally calculated and the actual warning/automatic braking distances for the LVM and LVD scenarios and a packet inter-reception time of 0.2 s. Every time a new update from the LV is received, the internally calculated distances (termed worst case in the figure and calculated every 0.05 s here) and the actual distances are equal, but begin to diverge immediately afterwards. Depending on the difference between the actual deceleration of the LV and the worst-case assumption, this gap can be significant or not.

The presented application logic, although shown for two-vehicle case, is also fail-safe for three- and more vehicle cases. Since application assumes the worst case situation change, i.e., the maximum physically possible deceleration of the leading vehicle, it does not matter whether the leading vehicle brakes on its own or because of a vehicle in front of him.

3.2. Efficiency tradeoff

Adjusting the warning to consider the "average driver" with average reaction time and average braking intensity requires automatic braking for all the drivers that are "worse" than average. The warning that accounts for "a worst driver" results in large inter-vehicle distances, but excludes automatic braking. The automatic braking does ensure fail-safety, but takes away vehicle control from drivers. A warning that accounts for "a best driver" will be more efficient with

Fig. 2. Flowchart of a fail-safe rear-end collision avoidance application running on the FV. FV is a following vehicle, LV is a leading vehicle, IVD is an inter-vehicle distance, DW is a warning distance, DAB is an automatic braking distance.

respect to traffic efficiency, but will require automatic braking for most of the drivers. On one side application can leave vehicle control to the drivers and would never have to automatically brake, but have to deal with highly inefficient traffic. On the other side, application can be highly efficient with respect to the traffic, and be a fully automated system with no control left for the drivers. Both systems are fail-safe.

3.3. Pre-crash scenarios

Rear-end crashes account for 32.9% of all accidents according to Ref. [37]. Following we describe the most frequent

pre-crash scenarios that result in a rear-end collision in order to evaluate our application [5].

Lead Vehicle Stopped (LVS)

According to Harding et al. [5] 61% of all rear-end crashes involving light vehicles were preceded by a lead vehicle stopped scenario. The relative speed in LVS scenario can be small, e.g., 50 km/h, representing urban scenario where FV is approaching the LV that is stopped at intersection. The relative speed can also be large, e.g., larger than 100 km/h, representing highway scenarios, where FV is approaching a traffic

(a) Lead vehicle is moving with a^v = 0g-

(b) Lead vehicle is decelerating with o,lv = —0.6<?

Fig. 3. Worst case assumption of the application on warning DW and automatic braking distances DAB based on information updates every IRT = 0.2 s, together with the actual values, assuming aLV stays the same. At time 0 s vF = 130 km/h, vL = 100 km/h.

Reaction Time [s]

-0.8 -0.75 -0.7 -0.65 -0.6 -0.55 -0.5 -0.45 -0.4 -0.35 -0.3 Braking intensity [g]

Fig. 4. Distribution of reaction time and braking intensity according to Brunson et al. [3].

lead Vehicle Moving (LVM)

According to Harding et al. [5] 13% of all rear-end crashes involving light vehicles were preceded by a lead vehicle moving scenario for which calculation of a warning distance is performed as in Eq. 1, where speed of FV is larger than speed of LV and speed of LV is larger than zero, vF > vL > 0. Automatic braking distance calculation follows the Eq. 1 with tR = 0 and aF set to max. physically possible deceleration of -0.8g.

4. Evaluation

4.1. Methodology

jam or a broken vehicle. The warning distance is calculated as follows:

Dw = ^--¿ap^2 + V - vi) • (tR + tsys) + Ds (1)

where vF and vL are speed of FV and LV respectively (vF > vL, vL = 0), tR is a reaction time of FV's driver and aF his braking intensity, tsys is a system delay and Ds is a desired safety gap at which FV wishes to come to the same speed as LV. In our study we set tsys = 0 and DS = 1m. An automatic braking distance Dab is calculated similarly to Eq. 1, with tR = 0 and aF as a braking intensity used by application, we set aF to maximum physically possible deceleration of -0.8g, other values can be used for smoother automatic braking.

Lead Vehicle Decelerating (LVD)

According to Harding et al. [5] 25% of all rear-end crashes involving light vehicles were preceded by a lead vehicle decelerating scenario. If a LV is decelerating the warning distance is calculated as follows:

dw = + vf • (tR + tsys)) + ik + ds (2)

where vF > vL, aF < 0, aL is an acceleration of LV (aL < 0). We use tsys = 0 and DS = 1m. Automatic braking distance calculation follows the Eq. 2 with tR = 0 and aF set to maximum physically possible deceleration of-0.8g.

We provide an analytical study for the evaluation of traffic and communication performance based on kinematic laws and an empirical communication model [38] that calculates the probability of packet reception based on the number of vehicles in the neighborhood, their beaconing rate, the size of a single beacon message, and the applied transmission power. We believe that a more red simulation model does not provide more insights for the indicators of our study as the used empirical model is already based on the results of detailed simulation studies. The underlying network simulations employed rather pessimistic radio propagation conditions at short distances, i.e., distances smaller than 100 m. Hence the probabilities of packet reception, as calculated by the empirical model, are lower than what can be expected in reality. Yet, a more realistic model will be required in case of an evaluation of traffic flow smoothness, e.g. when looking at adaptive cruise control applications, however, this is out of scope of this study.

In the following we calculate the maximum warning and automatic braking distances that result due to various IRTs, instead of showing the evolution of DW and DAB over time as in Fig. 3.

To evaluate and quantify the safety-efficiency tradeoff we first, generated "driver profiles" with reaction time and braking intensity given in [3]. Fig. 4 shows the distribution of reaction time and distribution of braking intensity. We generated 500 samples with each distribution, thus each "driver profile" or simply a driver represents a combination from one sample out of reaction time distribution and one sample out of braking intensity distribution, totaling of 250,000 drivers.

Table 1

The multi-lane highway Level of Services for a free-flow speed of 100 km/h, according to exhibit 21-2 in [7].

LOS Description Max. Veh. Density 0 Speed

[veh/km/ln] [km/h]

A complete free flow 7 100.0

B free flow 11 100.0

C marked influence of other vehicles presence 16 98.4

D traffic congestion 22 91.5

E near capacity, unstable level 25 88.0

For each pre-crash scenario and for each of the 250,000 drivers, the "individual warning distance" is calculated according to formulas given in Section 3.3. The CDF of these warning distances shows the warning distances that provide enough time for a certain amount of driver population to react. If application gives a warning that allows enough time to react to e.g., 90% of all drivers, then for 10% of all drivers automatic braking is needed. The automation level refers to this share of drivers that require automatic braking and thus are deprived of a vehicle control. The traffic density calculation is possible in the following way: if the warning distance that suits 90% of all drivers is at IVD of 194.5 m then, accounting average vehicle length of 5.5 m, the possible traffic density for a fail-safe rear-end collision avoidance application is 5 veh/km/lane.

We compare the resulting vehicle density with the Level of Services (LOS) provided by the Highway Capacity Manual [7]. The Level of Service (LOS) characterizes the performance of portions of the transportation system. Table 1 summarizes these LOS classes for a multi-lane highway with their corresponding maximum vehicle density and average vehicle speed.

We further compare the IVD against road traffic regulations in Germany which indicate that the minimum inter-vehicle distance should be large enough to ensure enough space to react for a sudden braking of the LV. The penalty starts when speed is larger than 80 km/h and IVD is less than a quarter of the speedometer value in meters.

At last, we evaluate the feasibility of IEEE 802.11p to support a fail-safe RECA application for the investigated scenarios and resulting traffic densities. In particular, it might be counter-productive to increase automation level in order to accommodate higher vehicle densities, not only due to decrease of LOS, but also due to resulting congestion in the communication channel. We make use of the empirical model presented in [38] and the awareness principles described in [39]. The empirical model accounts for radio propagation with Nakagami m = 3, inputs default packet size of 400 bytes, variable parameters like vehicle density, transmission power and rate, and calculates the corresponding probability of packet reception. The awareness principle is based on the calculated probability of packet reception, and determines the awareness distance at which n packets within a time window T are received with a certain probability (set to 99.99% in our evaluation if not stated otherwise). We assume that all vehicles communicate with the same transmission rate of 10 Hz while the transmission power is adjusted to "guarantee" the reception at various

—1— FV speed = 160 km/h, Dab «127m

—m— FV speed = 130 km/h, Da0 «85m

—в— FV speed = 100 km/h, Dab «51m

—©— FV speed = 80 km/h, DA0. 33m

—«— FV speed - 50 km/h, Daq « 14m

200 300 400 500 600 Warning Distance[m]

(a) The CDF of warning distances for 250000 drivers

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 Automation Level

(b) Vehicular density for various automation levels Fig. 5. Lead vehicle stopped scenario.

warning distances. Please refer to [38] and [39] for more details.

4.2. Results

Lead vehicle stopped scenario

If LV is stopped and the worst case assumption between packet reception is that the LV is still at stop, then the duration of packet inter-reception time does not play a role in calculation of DW or DAB.

Fig. 5 a plots the CDF of the warning distance for the generated driver profiles using different speeds for the FV. As can be seen, most of the drivers share a similar warning distance, and the warning distance decreases with decreasing FV speed. For instance, if the curve for FV speed of 80 km/h is considered, a warning distance of 143 m is necessary to provide enough reaction time to 99% of all drivers, which in turn translates to a vehicle density of 6.73 vehicles/km per lane (cf. Fig. 5b). In terms of LOS this maps to a completely free flow level of A. On the contrary, if only 1% of all

Table 2

Awareness distances in a LVS scenario with 8 lanes, a FV speed of 50 km/h, a transmission power that equals a 100 m communication range, and a 10 Hz beaconing rate. The offered channel load is 2.41 Mbps which equals approx. 40% in a 6 Mbps configuration. In comparison, the warning distance is 16 m and the automatic braking distance is 14 m in this scenario.

Prob. of awareness (%) Time window (i.e. IRT)

0.2 s 0.4 s 0.6 s 0.8 s 1.0 s

99.9999 0m 6 m 18 m 26 m 31 m

99.999 0m 12 m 23 m 30 m 35 m

99.99 1m 18 m 28 m 35 m 39 m

99.9 6 m 26 m 35 m 41 m 45 m

drivers is given enough time to react, a warning distance of 47 m is sufficient, which in turn translates to a vehicle density of 19.05 vehicles/km per lane and a congested traffic situation (LOS D). In both cases, the automatic breaking distance for the moving vehicles is 33 m, which, compared to German traffic regulations, is still above the penalty threshold of 20 m. The comparison also holds for all other automatic braking distances at higher FV speeds, which are shown in the legend of Fig. 5a.

With respect to the question whether IEEE 802.11p is able to fulfill the RECA application requirements, it is best to take a look at the most demanding scenario: FV speed of 50 km/h and automation level of 100%. In this scenario, a warning distance of 16 m is necessary, which translates to a vehicle density of 46.5 vehicles/km per lane. As the answer to this question is not black and white, Table 2 lists the awareness distances for different awareness probabilities and time windows for a 8-lane highway configuration. As can be seen, the achievable awareness distance is lowest for a high probability requirement and a short time window. When comparing these awareness distances with the warning distance of 16 m and the automatic braking distance of 14 m (cf. Fig. 5a) it becomes clear that a very high awareness probability, and hence a high level of safety, is only achievable for a time window of 0.6 s and greater. In non-technical terms, this means that a time window of 0.6 s is sufficient to detect a LVS situation with a 99.9999% probability and react in time. For lower detection times only lower probabilities are feasible. If shorter detection windows are envisioned, a lower awareness probability has to be accepted.

It should be noted that the above calculations are based on worst case assumptions: first, a FV speed of 50 km/h is not realistic if all other vehicles share an IVD of 16 m. Second, the used empirical communication model assumes strong fading even at close distances, which is not in line with what field tests have shown.

Lead vehicle moving and lead vehicle decelerating scenarios

Fig. 6a shows the CDF of the warning distance for both, the LVM and LVD scenarios. Their results match each other if IRT > 0 as they only differ in the actual deceleration value of LV, which is aL = 0 in the LVM scenario and aL = -0.6g in the LVD scenario. This value however does not have an impact on the calculation of the RECA application as it always assumes the worst case deceleration of LV, i.e. aL = -0.8g.

LVM: IRT = 0s, Dab = 6m —*— LVD: IRT - 0s, D^ - 35m —B— IRT = 0.1s, D^ - 38m —0— IRT = 0.2s, D^ = 41 m —*— IRT = 0.4s, Dab » 46m —A— IRT = 0.6s, D№ = 51 m —e— IRT = 1s, DAB = 59m

0 50 100 150 200 250 300

Warning Distance[m]

(a) The CDF of warning distances for all 250000 drivers

(b) Vehicular density for various automation levels

Fig. 6. LVM and LVD Scenario for vF = 130 km/h and vL = 100 km/h for different IRTs.

As can be seen in Fig. 6a, the IRT has a strong impact on the warning and automatic braking distance, and the gap to the curve for IRT = 0 is most significant in the LVM case. The LVM scenario is not the most challenging, but the one that results in the largest error. We focus on both, LVM and LVD, since their worst case assumption is the same.

Fig. 6b shows the achievable vehicle densities for the different configurations with respect to the applied level of automation. If an IRT of 0.2 s and an automation level of zero is targeted, the warning distance equals approx. 236 m, which translates to a vehicle density of 4.14 vehicles/km per lane. By increasing the automation level to 1, i.e. such that all drivers are too slow to react in time, the warning distance reduces to 49 m, which translates to a vehicle density of 18.34 vehicles/km per lane. Whether the wireless communication system is able to provide a reliable service in this setup is answered by Fig. 7. Fig. 7a and b plot the maximum achievable awareness reliability and the resulting channel load (in Mbps) for the above scenario (1RT=0.2 s) with respect to the automation level and the number of lanes considered. Each shown reliability value stems from the optimal combination of transmit power and transmission range. As can be seen, the reliability increases with an increasing automation level as long 6 lanes or less are considered. The reliability reaches even 100% in the 2 lanes setup if the automation level is above 10%. In the 8 lane and 10 lane scenario, the wireless communication system is not able to provide a highly reliable service, and the increase of the automation level helps only up to a certain point. A look at Fig. 7b further reveals that the offered load never exceeds 1.6 Mbps, which is less than 27% of the available 6 Mbps. Please note that the load curves vary with respect to the automation level and that no clear tendency is visible. This is

2 Lanes -4 Lanes -

0.4 0.6

Automation Level [%]

(a) Awareness Reliability, IRT=0.2s

Automation Level [%]

6 Lanes —b— 10 Lanes -8 Lanes —e—

(b) Channel Load, IRT=0.2s

2 Lanes 4 Lanes

0.9994 0.9993

4 Lanes

Automation Li - 6 Lanes 8 Lanes

ïl [%],

(c) Awareness Reliability, IRT=0.4s

2 Lanes -4 Lanes -

Automation Level [%]

- 6 Lanes—s— 10 Lanes-

- 8 Lanes —e—

(d) Channel Load, IRT=0.4s

£ 0.99998

0.99997 0.99996 0.99995 0.99994 0.99993 0.99992 0.99991 0.99990

2 Lanes -4 Lanes -

Automation Level [%]

- 6 Lanes —h— 10 Lanes -

- 8 Lanes —e—

(e) Awareness Reliability, IRT=0.6s

2 Lanes -4 Lanes -

Automation Level [%]

- 6 Lanes —b— 10 Lanes -

- 8 Lanes —e—

(f) Channel Load, IRT=0.6s

Fig. 7. Maximum achievable awareness reliabilities (i.e. awareness probabilities) at the respective warning distances (sub-figures (a), (c) and (e)) as well as the resulting channel load in Mbps (sub-figures (b), (d) and (f)), both with respect to the automation level and the number of lanes considered.

a result of the fact that different transmission rate and range combinations yield the optimal awareness reliability.

When considering an IRT of 0.4 or 0.6 s, the wireless communication system is less challenged, as can be seen in Fig. 7c-f. Consequently, higher awareness reliabilities can be achieved. This is to be expected as an increase of the IRT increases the time windows during which at least one packet has to be received successfully. At the same time, the load on the wireless channel is kept at a similar level as before.

4.3. Discussion

We investigated the most frequent pre-crash scenarios to evaluate the maximum traffic densities that are supported by fail-safe rear-end collision avoidance application. Designed fail-safe application does not aim to minimize nuisance alerts, resulting in a non-optimal IVDs when obedient driver is assumed. Nevertheless, such IVDs allow reasonable traffic density that can be reflected by highway level of services, up to LOS E. Moreover, by adjusting the automation level application can control the maximum traffic den-

sity. The IEEE 802.11p communication can support communication in resulting traffic densities if scaled up to an 8-lane highway with reasonable channel load of around 40%. The possibility for nuisance alerts comes due to a non-zero packet IRT when the difference between actual traffic situation and what application assumes to ensure fail-safety occurs. There are multiple ways to reduce this discrepancy and thus nuisance alert probability. For example, it is safe to assume that the LV will transmit the Decentralized Environmental Notification Message (DENM) in case of emergency braking [5]. Thus, application's logic can assume less intense braking as a worst case traffic situation change assumption. Adaptive transmission rates, especially when IVD is close to DW or Dab, could help reducing the nuisance alert probability as well as hybrid approach of IEEE 802.11p communication together with sensor-based technologies, e.g., a radar. In hybrid approach the weakness of one technology can be supported by the strength of the other, as also has been pointed out in [5]. These techniques may help maintain the warning distance accuracy within ± 15% foreseen in the ISO 15623 standard [4].

5. Conclusion

1n the current paper we presented a methodology to design a fail-safe rear-end collision avoidance application that is purely based on IEEE 802.11p. As expected, our results state that higher traffic densities can be achieved ifcontrol is taken away from the user and delegated to the application. We further quantified this relationship between the level of automation, i.e. the amount of drivers that have to give up vehicle control to the application, and the resulting traffic efficiency. This understanding is essential in order to properly balance this trade-off and to smoothen the transition from semi- to fully-automated traffic. The resulting traffic densities match to the highway LOS that are seen on today's highways. Moreover, the IEEE 802.11p communication is able to support traffic density on highways with up to 8-lanes while generating acceptable channel loads of around 40%. The designed application logic, although shown on a two-vehicle case example is also fail-safe and traffic efficient for a three-and more vehicle case.

References

[1] S. Joerer, M. Segata, B. Bloessl, R.L. Cigno, C. Sommer, F. Dressier, A vehicular networking perspective on estimating vehicle collision probability at intersections, IEEE Trans. Veh. Technol. (2014).

[2] N. An, M. Maile, D.Jiang, H. Hartenstein, Balancing the requirements for a zero false positive/negative forward collision warning, in: Proceedings of the 10th Annual Conference on Wireless On-Demand Network Systems and Services (WONS), 2013.

[3] S.J. Brunson et al., Alert Algorithm Development Program. NHTSA Rear-End Collision Alert Algorithm. Final Report, Technical Report DOT HS 809 526, U.S. Department of Transportation, National Highway Traffic Safety Administration, 2002.

[4] 1nternational Organization for Standardization, 1ntelligent transport systems - Forward vehicle collision warning systems - Performance requirements and test procedures, 2013, 1SO 15623.

[5] J. Harding et al., Vehicle-to-Vehicle Communications: Readiness ofV2V Technology for Application, Technical Report DOT HS 812 014, U.S. Department of Transportation, National Highway Traffic Safety Administration, 2014.

[6] M. Goppelt, et al., Automotive radar - investigation of mutual interference mechanisms, Adv. Radio Sci. 8 (2010) 55-60.

[7] Highway Capacity Manual, Technical Report, Transportation Research Board. National Research Council, 2000.

[8] T.B. Wilson, W. Butler, D.V. McGehee, T. Dingus, Forward-Looking Collision Warning System Performance Guidelines, Technical Report 970456, SAE, 1997, doi:10.4271/970456.

[9] G.R. Widmann, W.A. Bauson, S.W. Alland, Development of collision avoidance systems at delphi automotive systems, in: Proceedings of the 1998 IEEE International Conference on Intelligent Vehicles, 2,1998, pp. 353-358.

[10] International Organization for Standardization, Intelligent transport systems - forward vehicle collision mitigation systems: Operation, performance, and verification requirements, ISO 22839.2013.

[11] CarHistory4u, History of cruise control in motor cars/automobiles, http://www.carhistory4u.com/. Accessed: 2015-01-20.

[12] D. Crolla, D.E. Foster, T. Kobayashi, N. Vaughan, Encyclopedia of Automotive Engineering, A John Wiley & Sons, Inc. Publication, Hoboken, New Jersey, 2015.

[13] R. Rajamani, Vehicle Dynamics and Control, 2, Springer, 2012.

[14] International Organization for Standardization, Intelligent transport systems - Adaptive Cruise Control systems - Performance requirements and test procedures, ISO 15622 2010.

[15] International Organization for Standardization, Intelligent transport systems - Full speed range adaptive cruise control (FSRA) systems - Performance requirements and test procedures, ISO 22179 2009.

[16] A. Girard, J. de Sousa, J. Misener, J. Hedrick, A control architecture for integrated cooperative cruise control and collision warning systems, in: Proceedings of the 40th IEEE Conference on Decision and Control, vol. 2, 2001, pp. 1491-1496, doi:10.1109/.2001.981105.

[17] D. de Bruin, J. Kroon, R. van Klaveren, M. Nelisse, Design and test of a cooperative adaptive cruise control system, in: Proceedings of the IEEE Intelligent Vehicles Symposium, 2004, pp. 392-396, doi:10.1109/1VS.2004.1336415.

[18] B. van Arem, C. van Driel, R. Visser, The impact of cooperative adaptive cruise control on traffic-flow characteristics, IEEE Trans. Intell. Transp. Syst. 7 (4) (2006) 429-436, doi:10.1109/T1TS.2006.884615.

[19] J. Ploeg, B. Scheepers, E. van Nunen, N. van de Wouw, H. Ni-jmeijer, Design and experimental evaluation of cooperative adaptive cruise control, in: Proceedings of the 14th International IEEE Conference on 1ntelligent Transportation Systems (1TSC), 2011, pp. 260-265, doi:10.1109/1TSC.2011.6082981.

[20] C. Lei, E. van Eenennaam, W. Wolterink, G. Karagiannis, G. Hei-jenk, J. Ploeg, Impact of packet loss on CACC string stability performance, in: Proceedings of the 11th International Conference on ITS Telecommunications, (1TST), Saint Petersburg, Russia, 2011, pp. 381386, doi:10.1109/1TST.2011.6060086.

[21] B. Kloiber, T. Strang, F. de Ponte Muller, Slipstream cooperative adaptive cruise control - a conceptual its application for electric vehicles, in: Proceedings of the 1EEE 1nternational Electric Vehicle Conference (1EVC), 2012, pp. 1-5, doi:10.1109/1EVC.2012.6183170.

[22] V. Milanes, S. Shladover, J. Spring, C. Nowakowski, H. Kawazoe, M. Nakamura, Cooperative adaptive cruise control in real traffic situations, 1EEE Trans. 1ntell. Transp. Syst. 15 (1) (2014) 296-305, doi:10.1109/T1TS.2013.2278494.

[23] R.J. Caudill, W.L. Garrard, Vehicle-follower longitudinal control for automated transit vehicles, J. Dyn. Syst. Meas. Control 99 (4) (1978) 241248, doi:10.1115/1.3427114.

[24] S.E. Shladover, Longitudinal control ofautomated guideway transit vehicles within platoons, J. Dyn. Syst. Meas. Control 100 (4) (1978) 302310, doi:10.1115/1.3426382.

[25] J. Hedrick, D. McMahon, V. Narendran, D. Swaroop, Longitudinal vehicle controller design for ivhs systems, in: Proceedings of the American Control Conference, 1991, pp. 3107-3112.

[26] P.P. Milestone, PATH Project Milestone: 4-car platoon demos a significant step for 1VHS, 1ntellimotion 2 (1) (1992) 1-2.

[27] C. Thorpe, T. Jochem, D. Pomerleau, The 1997 automated highway free agent demonstration, in: Proceedings of the 1EEE Conference on 1ntel-ligent Transportation Systems, 1997, pp. 496-501.

[28] T. Robinson, E. Chan, E. Coelingh, Operating platoons on public motorways: an introduction to the sartre platooning programme, in: Proceedings of the 17th 1TS World Congress, 2010.

[29] P. Barber, N. Clarke, Advanced collision warning systems, in: Proceedings of the 1EE Colloquium on 1ndustrial Automation and Control: Applications in the Automotive 1ndustry (Digest No. 1998/234), 1998 2/12/9, doi:10.1049/ic:19980211.

[30] K. Lee, H. Peng, Evaluation of automotive forward collision warning and collision avoidance algorithms, Veh. Syst. Dyn. 43 (10) (2005) 735-751.

[31] R. Kiefer, D. LeBlanc, M. Palmer, J. Salinger, R. Deering, M. Shulman, Development and Validation of Functional Definitions and Evaluation Procedures for Collision Warning/Avoidance Systems, Technical Report DOT HS 808 964, U.S. Department of Transportation, National Highway Traffic Safety Administration, 1999.

[32] The European Commission, Commission regulation (EU) No 347/2012 of 16 April 2012 implementing regulation (EC) No 661/2009 of the European parliament and of the council with respect to type-approval requirements for certain categories of motor vehicles with regard to advanced emergency braking systems, Off. J. Eur. Union (2012). 1.109/1-1. 109/17.

[33] V. Milanes, J. Prez, J. Godoy, E. Onieva, A fuzzy aid rear-end collision warning/avoidance system, Expert Syst. Appl. 39 (10) (2012) 90979107.

[34] X. Yang, J. Liu, N. Vaidya, F. Zhao, A vehicle-to-vehicle communication protocol for cooperative collision warning, in: Proceedings of the 1st Annual 1nternational Conference on Mobile and Ubiquitous Systems: Networking and Services, (MOB1QU1TOUS), 2004, pp. 114-123, doi:10.1109/MOB1Q.2004.1331717.

[35] M. Segata, R. Lo Cigno, Automatic emergency braking: realistic analysis of car dynamics and network performance, 1EEE Trans. Veh. Technol. 62 (9) (2013)4150-4161, doi:10.1109/TVT.2013.2277802.

[36] R. Roess, E. Prassas, W. McShane, Traffic Engineering, Pearson Education 1nternational, 2004.

[37] Traffic Safety Facts, A Compilation of Motor Vehicle Crash Data from the Fatality Analysis Reporting System and the General Estimates System, Technical Report DOT HS 812 032, U.S. Department of Transportation, National Highway Traffic Safety Administration, 2012.

[38] M. Killat, H. Hartenstein, An empirical model for probability of packet reception in vehicular Ad Hoc networks, EURAS1P J. Wirel. Commun. Netw. (2009).

[39] N. An, T. Gaugel, H. Hartenstein, Is 95% probability of packet reception safe? in: Proceedings of the 11th International Conference on Intelligent Transport Systems Telecommunications, Russia, 2011.

Natalya An received her M.Sc. degree from RWTH Aachen University in Communications Engineering in 2008. She is currently working towards the Ph.D. degree in the Decentralized Systems and Network Services Research Group at Karlsruhe Institute of Technology, Germany. Her research interests include inter-vehicle communications with a particular focus on safety-critical driver assistance applications.

Jens Mittag received his diploma and Ph.D. degree in Computer Science from the Karlsruhe Institute of Technology, Karlsruhe, Germany and is currently employed as CTO in the German startup DATAGNAN which develops secure personal home cloud solutions. He has contributed to the standardization of inter-vehicle communication networks at the European Telecommunications Standard Institute and was previously employed by the Barcelona Digital Technology Centre, Spain, as a product and development manager in the context of smart city platforms.

Hannes Hartenstein is a full professor of computer science and a director of the Steinbuch Centre for Computing at the Karlsruhe Institute of Technology, Karlsruhe, Germany. He received a diploma degree in mathematics and a Ph.D. degree in computer science from Albert Ludwigs University, Freiburg, Germany. Prior to joining KIT, he was a senior research staff member at NEC Europe. His research interests include mobile networks, virtual networks, security, and information technology management. He is a member of the scientific directorate of the Leibniz Centre for Informatics, Schloss Dagstuhl.