**1. Introduction**

In the last few years, a swelling phenomenon of crashes between vehicles and pedestrians [1], which has induced many injuries and even more deaths, has been witnessed [2,3]. Pedestrians, cyclists, and other non-vehicle occupants made up a considerable percentage of people killed in motor vehicle traffic crashes. Notwithstanding a constant lessening in the number of roadway fatalities, the number of pedestrian and cyclist fatalities has been nearly constant. As a consequence, these vulnerable groups have unique safety requirements and challenges that must be addressed. Thus, the protection of pedestrians, cyclists, and other non-vehicle occupants is part of the research areas regarding connected and automated vehicles [4]. In most cases, pedestrians collide with vehicles due to the distraction caused by their interactions with smartphones [5] or other Internet of things (IoT) devices [6–8]. This circumstance determines a decrease in the attention threshold and causes hazardous neglects during the crossing of roads [9–11]. Although there are some traditional mechanisms to protect pedestrians from vehicles [12], most of these are fundamentally linked to a pedestrian's acoustic warning [13]. However, this solution is often not adequate to divert the pedestrians' attentions from their smartphones. Pedestrian detection systems can be implemented in vehicles, in the infrastructure, or with pedestrians themselves to give warnings to drivers, pedestrians, or both. In-vehicle warning methods are becoming more and more conventional, for instance, blind-spot warning and forward collision warning. The contemporary field of vehicle-to-vehicle (V2V) communications is affording the

advancement of high-level warning systems, such as intersection movement assist or left turn assist. In-vehicle warnings to the neighborhood of a pedestrian on the road might be logical. On the contrary, reasonably, the most straightforward and obvious warning system for pedestrians is a handheld device.

Fortunately, smartphones are becoming increasingly present and intelligent in people's daily lives [14,15]. It is also true that particular applications have been developed to provide proper alarms for pedestrians by using vehicle-to-pedestrian (V2P) communications [16,17]. In this paper, the concepts for the development of an approach based on V2X communications aiming at vehicle and pedestrian safety is proposed. The primary purpose of this work is not to present a solution that has already been implemented and tested. For this reason, performance evaluation is not carried out. Instead, this article aims to introduce the fundamental notions that a potential application for driver and pedestrian safety should support. To this end, we propose a possible hardware and software architecture that could be used in vehicles and mobile devices.

In this research field, the approach suggested in ref. [18] consists of an on-board unit (OBU) system designed for vehicles, which uses the IEEE 802.11p [19] standard in agreemen<sup>t</sup> with Wi-Fi protocols. The IEEE 802.11p protocol is an evolution of the IEEE 802.11 family, which introduces appropriate improvements aimed at supporting intelligent transport system (ITS) applications [20–24]. A more detailed validation of the OBU allows the realizing of a reliable V2V and V2P communication [25,26], both concerning the package delivery speed and the average delay [27]. Besides, in the literature, several security applications have been proposed to protect the safety of vehicles and pedestrians based on data transferred from the OBU. For instance, the solution introduced in refs. [28,29] is designed for showing driving information and providing a collision warning alarm on a tablet inside the vehicle. On the contrary, the application presented in refs. [13,30] has been developed for the smartphone that is supposed to be owned by the pedestrian. In this way, vital warning information can be provided to vulnerable pedestrians distracted by the smartphone.

Different solutions have been developed, aimed at interacting with the particular action that the smartphone is playing in a precise moment, i.e., listening to music, making calls, sending text messages. Meanwhile, the privacy protection is also crucial for all participants during the data exchange processes [31,32]. Based on the precise moment, it will be possible to appropriately manipulate four specific parameters that will allow interacting in the best way with the pedestrian. In particular, these parameters are aimed at establishing:


The smart tuning and managemen<sup>t</sup> of these parameters and related applications can report accidents near road intersections, and pedestrians can receive more appropriate warnings, based on the use of their smartphone. The main contributions of the concepts introduced in this paper are:


This paper is organized as follows. Section 2 introduces a possible system architecture that can be used in the development of a safety application for vehicles and pedestrians, while specific concepts are analyzed in Section 3. Finally, Section 4 concludes the paper.

## **2. System Architecture**

The possible hardware architecture of the system is depicted in Figure 1. It is composed of three components: The OBU installed on the vehicle, the tablet inside the vehicle, and the pedestrian's smartphone. Modern vehicles incorporate a vast range of electronic components. Consequently, it would not be challenging to include ad hoc-created OBUs or tablets. In fact, concerning the latter, almost all cars now include touchscreen that allow various operations to be carried out, such as, for instance, interaction with the audio or infotainment system, air conditioning managemen<sup>t</sup> and vehicle parameters, and mirroring of different operating systems for mobile devices (iOS, Apple CarPlay; Android, Android Auto). Consequently, the implementation of ad hoc applications should not involve particularly complex efforts. Regarding the OBUs, they can be composed of multiple wireless interfaces, which permit the vehicles to communicate both with other vehicles and with roadside units. Considering the proposed architecture, the OBU includes a single-board computer, DSRC wireless interface (i.e., IEEE 802.11p), Wi-Fi interface (i.e., IEEE 802.11b/g/n/ac), cellular interface, GPS (global positioning system) receiver, and antennas for each technology, for instance, the round antenna for Wi-Fi and the rectangular antenna for IEEE 802.11p. The OBU is designed for interconnecting the different subsystems. Vehicle information can be collected by connecting the on-board diagnostic (OBD) interface and GPS. Information on surrounding vehicles can be collected through the IEEE 802.11p protocol. Smartphones and tablets can communicate with the OBU via the Wi-Fi system. With the information gathered from the OBU, it is feasible to warn vehicles and pedestrians of possible and imminent collisions. Besides, the tablet can keep the driver updated with critical supporting information.

The functional software architecture, as shown in Figure 2, can be composed of three parts. Regarding the OBU, it is fundamental to focus more attention on the implementation of the dedicated short-range communications (DSRC) and the coexistence between Wi-Fi and IEEE 802.11p. As for the smartphone, the goal is to provide reliable and efficient pedestrian warnings. In this sense, the notice of a possible collision arriving in the most appropriate mode can be provided, taking into account the detection of the specific state of the smartphone. The collision warning can also be provided to the tablet that is inside the vehicle. Notwithstanding, this warning will not prevent the driver from taking advantage of additional dedicated driving assistance information.

Regarding the coexistence between Wi-Fi and IEEE 802.11p, both protocols have different MAC80211 mechanisms. In most cases, it is difficult to run the IEEE 802.11p and Wi-Fi simultaneously. For instance, IEEE 802.11p [19] defines a way to exchange data without the need to establish a basic services set (BSS), while Wi-Fi protocols must connect to the BSS and wait for the association and authentication procedures before being able to exchange data. Therefore, the problem to be solved is to make it possible for these two different protocols to share MAC80211, which is one of the leading locks in the Linux wireless subsystem [33]. A flag serves to distinguish the IEEE 802.11p and Wi-Fi protocols in the MAC80211. The wireless network adapter is examined to identify the different protocols. In particular, in the struct net-device, there is a flag called ht-supported, which is used to define if a wireless network adapter can support a particular protocol, and, based on this, the protocol it can work with is established. It is necessary to note that the V2P communication for safety systems based on Wi-Fi could have some limitations:


Several systems are in a developing and researching phase, which, in most cases, have not been employed in the real world. Although most of the systems have validated the Wi-Fi reliability, the test carried out under particular conditions cannot be on behalf of the complex conditions in the real world. It is essential to examine more in detail these systems, like the one proposed in this paper in case of real implementation, with a particular focus on the reliability to improve the safety of the traffic situation. Besides, the vehicular ad-hoc network employed in the V2P safety is almost a new research field. A careful assessment of the existing pieces of literature is essential for the development of Wi-Fi-based fault-tolerant solutions.

**Figure 2.** The proposed software architecture.

Before introducing the different characteristics of applications for the safety of drivers and pedestrians, it is advisable to perform a brief analysis regarding other distinctions of V2X communications. They are not presumed to have high latency toleration because safety-related applications require ultra-low latency [34]. For instance, pre-crash sensing alarms typically expect a cumulative latency of less than 50 ms [35]. It is necessary to note that V2V communications based on IEEE 802.11p, in most circumstances, must be conducted in non-line-of-sight conditions, while those that are cellular-based operate more trustworthily in transmission reliability, but produce more significant latency than IEEE 802.11p. Moreover, Wi-Fi-based V2P communication is useful when the transmission range is less than 150 m. Considering that these protocols are taken into account in the approach proposed in this paper, in a possible concrete implementation, these metrics should be recognized. Another characteristic to evaluate is related to communication security [36,37]. Data exchange between vehicles and other elements can be complicated as numerous data formats are transferred within various networks. One crucial concern is whether the data obtained from the V2X networks can be trusted, primarily if it is practiced for safety-related applications. For instance, an intruder could alter the transmitting operation to broadcast incorrect data deliberately. Further, data transferred in the V2X network might be modified by an attacker to mislead vehicles, which may lead to traffic accidents. Proper security schemes can be adopted, but extra latency may be introduced [38].

## **3. Concepts for Safety Applications**

## *3.1. Vehicle Safety Application*

Since the OBU does not have a user interface (UI) to interact with the driver, the vehicle security application is developed on a tablet and allows driving information to be displayed and collision warnings to be provided. After connecting to the OBU's Wi-Fi, the tablet can ge<sup>t</sup> the driving information of the surrounding vehicles. The GPS module installed in the OBU can provide location and speed information. The OBU allows for controlling several essential vehicle parameters, such as the speed or current fuel consumption, through the OBD-RS232 interpreter installed in the vehicle. It is useful to note that the measurements relating to the speed supplied by the OBD are more precise than those provided by the GPS.

As mentioned above, the OBU can obtain driving information on surrounding vehicles through the use of the IEEE 802.11p. As a consequence, the latter can also be used to estimate an incoming collision. In general, after receiving a package via IEEE 802.11p, the OBU can transfer it through Wi-Fi to the tablets and smartphones. With all this information obtained via Wi-Fi, thanks to the vehicular ad-hoc network (VANET) [39–44] application, it is possible to help the driver in monitoring vehicle status and threats from surrounding vehicles [45]. When the tablet estimates an incoming collision, it will inform the driver with a warning on the screen and a voice alert. The detailed information screen can display some parameters related to the surrounding vehicles, such as the position (longitude and latitude), driving speed, direction, and acceleration. After the tablet has received information on surrounding vehicles, it will notify the driver about the possibility of these vehicles generating a collision, thus ensuring more excellent safety for motorists. Moreover, attention appears to be focused mainly near road intersections, areas typically more characterized by possible clashes between motor vehicles [46].

Finally, when the tablet receives messages from the vehicle on which it is installed and other data by the surrounding vehicles, it can translate the latitudes and longitudes of the rectangular coordinate system of the Gauss–Krueger plane. Then, it estimates the driving vector of each vehicle and finds potential vehicles that cross with the vehicle concerned. If the carriers have an intersection nearby, they will calculate the time of the current vehicle and the vehicle with which it could crash. If these two times are below the threshold of the safety reaction time, then these two vehicles will have the risk of crashing each other.

## *3.2. Pedestrian Safety Application*

Parallel to the application developed for the safety of motor vehicles, a smartphone security application can also be developed, useful for safeguarding distracted pedestrians. With messages received from the OBU via Wi-Fi [47], the application can provide the alert in the most appropriate mode based on the state of the smartphone. Concerning smartphones, in recent years, there has been a significant growth regarding their performance. Even mid or low range devices achieve remarkable performance, which until a few years ago was unthinkable for smartphones of these categories. This goal has been made possible thanks to an implicit standardization of the components to be used in terms of CPU, memory, and wireless protocols, such as cellular networks, Bluetooth, and Wi-Fi. The manufacturers of the most popular operating systems (Apple—iOS; Google—Android) now differentiate their products only for very small functionality, mostly focused on the use of artificial intelligence or augmented reality. The functioning of the apps is almost the same in both operating systems. Consequently, the diversity of operating systems is not a problem. Some small differences in performance could be found between high-level and low-level smartphones due to the diversity of the used hardware. Anyhow, it is evident that, in the future, the minimum requirements regarding the hardware and version of the operating system could be standardized to make the system work appropriately without incurring possible problems.

A possible implementation of the application is described in the flowchart depicted in Figure 3. First, the smartphone must access the open hotspot from the OBU, so that it can receive driving information from surrounding vehicles. After receiving a new package from the OBU, the smartphone will perform the collision estimation to recognize if the pedestrian could be run over by the vehicle. The application reads the GPS data of the smartphone to obtain the pedestrian position and information concerning its movement. Thus, the latitudes and longitudes of the smartphone and vehicle can be translated into the rectangular Gauss–Krueger plane. Next, the moving vectors of the smartphone and the vehicle will be calculated to see if they will have a collision. If the two carriers collide, the time required for the pedestrian and the vehicle to reach the intersection will be measured [14]. If the absolute time difference is lower than the safety intersection time threshold and the pedestrian crossing time is lower than the safety reaction time threshold, it is assumed that the pedestrian is at risk of being run over. With a positive collision prediction signal, a pedestrian alert is provided.

**Figure 3.** Application flowchart.

It has been already mentioned that pedestrians can use the smartphone in different ways. For each of these modes, the pedestrian will have to receive specific information, useful for grabbing attention during the specific activity performed. For instance, the specific examples can be classified into four categories: Reading an e-book, listening to music, watching and listening to a movie, inactive state. This classification is based on which specific part of the smartphone the user is focusing on. As a result, attention can be given to the screen rather than to the audio of the smartphone. The choice of the most suitable warning mode for the specific state of use is important to attract the pedestrian's attention. For example, a piece of sound information must be provided to capture the attention of the pedestrian. In each specific case, therefore, the most suitable warning mode corresponding to the state of use of the smartphone will be chosen. By analyzing the individual specific cases, it is possible to conclude that:

• In the screen-oriented state, the warning can consist of a message visible on the screen, i.e., the warning message is printed on the screen;

