# Autonomous Real-Time Speed-Limit Violation Detection and Reporting Systems Based on the Internet of Vehicles (IoV)

Authors: Samir A. Elsagheer Mohamed; Mohammad T. Parvez; Khaled A. AlShalfan; Mahmoud Y. Alaidy; Mohammed A. Al-Hagery; Mohamed T. Ben Othman
Journal: Journal of Advanced Transportation
 (2021)

---

## Abstract

Over-/underspeeding is one of the leading causes of road accidents. Traditional systems of detecting and reporting speed-limit violations are not suitable for smart cities. Even the sophisticated conventional systems that use cameras or RFIDs for automating speed-limit violations have several drawbacks, including cost, complexity, reliability, and maintenance. In this paper, we present two systems based on the Internet of Vehicles (IoV) to automatically detect speed-limit violations and autonomously report the committed violations to the authorities. Our systems require no extra hardware or equipment: only the On-Board Unit (OBU), the Road Side Unit (RSU), and the Cloud Server software have to be updated to have a fully functioning system as long as the IoV infrastructure is deployed. One of the systems will be installed on the OBU. A second alternative system design is to use Cloud Servers (CSs) and the IoV beacons that are sent from the vehicles. Additionally, unlike the existing systems installed in specific locations, all roads in the smart cities and highways will be fully monitored. Adaptive fine calculation according to new dynamic policies can be easily integrated into the proposed system. Furthermore, the proposed system can accurately operate in all weather conditions. Moreover, it allows the dynamic adjustment of the speed limits according to the current weather conditions. We have validated the proposed system by building a prototype system that effectively and accurately detects and reports over-/underspeed traffic violations alongside any road.


---

## Body

## 1. Introduction

Traffic rule violation is a major problem that affects society and the economy. Most road accidents are due to traffic rules’ violations. These accidents cause death, physical disabilities, and psychological disorders for people. The World Health Organization (WHO) reports that approximately 1.35 million people die every year due to road crashes. The actual figures are much higher because accidents are not reported to the authorities in several developing countries.Moreover, according to the WHO’s statistical reports, 54% of people who die from road accidents are vulnerable road users. In addition, the WHO has set a target to reduce road causalities to half by 2030 according to the Agenda for Sustainable Development [1]. It is obvious that limiting or reducing traffic accidents can be achieved by minimizing or eliminating traffic violations. Although there are different types of traffic violations, one of the most dangerous violations is overspeeding (driving at a speed more than the maximum legal speed limits). In some situations, driving on highways at a too slow speed, underspeeding, can also cause severe accidents. This paper focuses on over-/underspeeding (speed limit) traffic violation types only.The problem of speed-limit violation detection has been studied intensively for several decades. Traditional means are by using traffic patrols and speed radars. Radar signals can be jammed or detected by radar detectors, and thus, they are not effective. Traditional sophisticated systems include cameras and speed detector radars to automatically identify the vehicle plate numbers and send information to the traffic authority to collect fines. More advanced traditional methods are by using RFID tags on each vehicle and using several RFID readers to estimate the speed of each vehicle. The camera-based approach suffers from the same problems as the radar-based system. In addition, they are very complex (involving Computer Vision), expensive, and inaccurate.The traditional systems suffer from one serious problem, in addition to the cost, reliability, and flexibility. These traditional systems are usually installed in fixed locations. It is impossible to install a speed-limit detector every few meters to cover all roads. Therefore, they can only detect the speed-limit violations in a tiny fraction of the whole roads. Drivers can know the locations of these detectors and can slow down at these locations to avoid detection; then, the drivers can overspeed in the other segments (not covered). Social apps are widely developed and used to warn drivers about the location of speed cameras.Almost all existing speed-limit violation detection systems require the development and deployment of costly dedicated equipment. Internet of Vehicles (IoV) [2], which is a subset of Intelligent Transportation Systems (ITSs), enables plenty of auspicious smart transportation applications that can be deployed in smart cities and highways. Thus, instead of building and deploying dedicated systems for detecting speed-limit violations, we propose the use of IoV infrastructure to automatically detect speed-limit violations and to automatically report them to the traffic authorities to collect fines from the owner of the vehicles without any human intervention in the process.In this paper, we propose the use of Intelligent Transportation Systems (ITSs) and the Internet of Vehicles (IoV) to develop two smart, accurate, and efficient speed-limit violation detection systems. In addition, we present an automatic and autonomous reporting system of the committed speed-limit violations. These systems could be used in smart cities and highways to minimize speed-limit violations and to support the WHO’s Sustainable Development targets.IoV, once deployed, would enable the development of many useful applications related to safety [3–5], traffic management and optimization [6–8], road lighting control and monitoring [9], and infotainment [2]. The essential component of IoV is the smart vehicle that contains an On-Board Unit (OBU). OBU can be viewed as a vehicle computer with added IoV functionality and features (software and hardware). The legacy vehicle can be easily upgraded to be IoV capable by building the OBU and installing it in the vehicle. Vehicles can communicate with each other while moving on the road using Vehicle-to-Vehicle (V2V) communication. In addition, in IoV, the vehicles must communicate with an infrastructure that consists of interconnected Road Side Units (RSUs) installed alongside the road. Vehicles communicate with the infrastructure using V2I through the RSUs. A vehicle can communicate with the Cloud using V2C. Vehicles can communicate with pedestrians using V2P. There are many other communication types in IoV, such as V2G (grid), V2H (home), V2D (device), and V2R (road traffic sign). For more details, please refer to [3, 10, 11].The proposed systems in this paper are based on IoV technology. Few components and communication protocols will be used from IoV. The proposed systems will not require any extra hardware components to operate effectively. Only software update to the existing IoV stack is needed to implement speed-limit violation detection and reporting. In addition, an essential feature of the proposed technique is that it monitors all roads for any speed-limit violation. This means that any speed-limit violation committed on any location of the road will be detected.This paper presents two different systems to automatically and efficiently detect speed-limit violations based on IoV. In addition, we present a traffic violation reporting system to the traffic authorities. We present a new dynamic and adaptive fine calculation policy framework for the committed violations.The rest of this paper is organized as follows: in Section2, the related techniques and technologies are presented. The overall system architecture of speed-limit violation detection and reporting based on IoV is presented in Section 3. We present the two proposed speed-limit violation detection systems in Section 4. Speed-limit adaptive fine calculation framework is presented in Section 5. A prototype system developed for the validation of the proposed systems is outlined in Section 6. Finally, the conclusions and future directions are given in Section 7.


## 2. Related Techniques and Technologies

The following topics are relevant to this article: the advance in the positioning techniques, the traffic violation detection techniques, the ad hoc networking, the Vehicular Ad Hoc Network, and the security techniques to secure all communications.


### 2.1. Existing Speed-Limit Traffic Violation Recording Systems

The discussions here focus on two key issues: detecting the vehicle’s speed and extracting the official speed-limit information at the current location of the vehicle.Several works for detecting automatic traffic violations use different ways to estimate the speed of the vehicle. In [12], the vehicle speed is estimated using a motion plane-based approach considering the projection displacement difference (PDD). Here, the vehicle reference point is the same as the center of a vehicle license plate and is used to estimate the motion plane. Then, the displacement is estimated by mapping the plate position to the motion plane. Another work that uses customized hardware to estimate the speed is [13], where an array of active infrared sensors is used to report violation-related data to the data center. The work in [14] also uses customized hardware to estimate the speed of the vehicle. In [15], a speedometer using XBee is used to record the vehicle’s speed to compare with the network of Master XBees.The method in [16] uses Road Side Units (RSUs) in a Vehicular Ad Hoc Network (VANET) for estimating vehicular speed. Using information from nearby several RSUs, the speed of the vehicle can be estimated. A similar research proposal for detecting the speed-limit violation using VANET is presented in [17].The work in [18] uses a different approach for detecting traffic violations based on the real-time video feedback of CCTV cameras. The real-time video footage is analyzed to detect traffic violations, including speed-limit violations. Similar work is reported in [19] where IP (Internet Protocol)-enabled cameras are used to monitor the roads to monitor traffic violations. Another work that uses real-time video feedback for traffic monitoring is reported in [20]. In a similar approach, works in [13, 21, 22] explore the use of Unmanned Aerial Vehicle (UAV) for road safety, traffic, and highway infrastructure management.As for the second issue, different traffic violation recording systems use different approaches to extract the speed-limit information at the vehicle’s current location. The work in [23] attempts to detect the roadside signboards for speed-limit information using image processing and then notify the driver about the extracted information. In [15], a network of Master XBees is installed in every locality that can broadcast information about the speed limit of the locality.Different researchers used techniques for the notification and recording of traffic violations. The work in [23] uses Arduino and GPRS to send traffic violation data to the Cloud for processing. In [16], the traffic violation is computed and recorded in the Cloud from the data sent by Road Side Units. In [15], when speed-limit violation is detected (even after warning), the information regarding the vehicle registration number is transmitted to the master XBee installed specifically for the task. This master XBee is connected to the Cloud Server, and traffic data can be accessed from anywhere.


### 2.2. Internet of Vehicles (IoV)

Since this work utilizes the Internet of Vehicles (IoV) (a typical architecture of IoV is given in Figure1), a brief discussion of the key issues in IoV research is presented here. The use of IoV and VANET for Intelligent Transportation Systems has increased a lot in recent years [2, 24]. Due to the nature of its domain, IoV applications need greater data throughput, lower latency, higher security, and massive connectivity [24]. Emerging new applications in IoV requires seamless connectivity, edge, fog, software-defined, and named data network [25]. When deployed in smart cities, IoV applications need large-scale data sensing, collection, information processing, and storage [3].Figure 1
A universal Internet of Vehicles architecture for smart cities [3].A key concern in IoV and VANET is the security issue in the communicated data to/from vehicles. Using conventional cryptographic techniques may affect the performance of delay-sensitive networks such as IoV and VANETs. To overcome this issue, some researchers have proposed RFID (Radio-Frequency Identification) device-based authentication scheme for IoV [2].Another issue is the radio access technologies that are used in IoV applications. The work in [10] discusses reliable and scalable wireless transmissions for the Internet of Vehicles (IoV). With the massive amount of data transmitted in IoV applications, the work in [10] analyzed the performance of Vehicle-to-Vehicle (V2V) beacon broadcasting using random access-based (IEEE 802.11p). The work in [3] proposed a new architecture for the IoV applications in smart cities.The work in [26] studies the applications of machine learning (ML) to handle IoV requirements of ultralow latency, high reliability, high security, and massive connections of the next-generation (6G) network. The goal here is to assist in the evolution of intelligent radio (IR), and self-learning with proactive exploration.


### 2.3. Positioning Techniques

To locate mobile users techniques such as Time Difference of Arrival (TDOA), Enhanced Observed Time Difference of Arrival (E-OTD), Angle of Arrival (AOA), Time of Arrival (TOA), Received Signal Strength (RSS) indication [27], and GPS systems are used [28, 29]. Many of these methods suffer from issues such as security, the need for special types of antennas, highly complex design algorithms, high estimation time, and high cost. Several research attempts are conducted to provide secure location services and location verification to be sure that the vehicle is not cheating its current location [30–32].There are many other methods proposed for estimating the location of vehicles. Visible light-based positioning for IoV is discussed in [33]. The work in [34] proposed the use of nanointegrated devices to provide accurate distance estimation for VANET. The ego-positioning algorithm based on camera for IoV is presented in [35]. Moreover, Doppler-shifted signals to localize a vehicle by using two RSUs are proposed in [28].Several works focus on the relative locations between vehicles. The relative position between vehicles as well as between a vehicle and Road Side Unit (RSU) is studied in [36]. The authors attempted to optimize the nonranging technology such as DVHop algorithm (with chemical reaction optimization) to reduce the error of localization. Similarly, the authors in [37] propose a method to study the behavioral correlation between vehicles to cluster them. Then, deep learning is used to predict the vehicles’ future location distribution. The work in [38] also deals with the noisy observation of the pairwise distance and the angle between vehicles and considers this as a nonlinear optimization problem, which is solved by deep learning models. Another word for relative localization for ground vehicles is [39], where UAV is used for ranging measurements with ground base stations and other UAVs in the round-trip time mode.In [40], the authors take a different approach for correcting the location estimation by a technique called collaborative driving. They try to correct GPS errors of a legacy car if that car encounters a sensor-rich car in a downtown scenario where GPS accuracies can be bad. The authors in [40] report that GPS error for legacy vehicles is reduced from 90% to 30% for sensor-rich vehicles. Another work that deals with correcting the GPS locations is [41]. Here, the authors propose an assistant vehicle localization method based on direction-of-arrival (DOA) estimation to improve the accuracy of vehicle localization. The proposed system is very complex, consisting of a minimum of three multiple-input-multiple-output (MIMO) base stations (BSs). The positions of the three BSs and the DOAs of vehicles estimated by the BSs are used to estimate the locations of the vehicles.The work in [42] deals with users’ location privacy: designing a realistic, privacy-preserving positioning system based on fingerprinting. The work in [27] studies the effect of the Received Signal Strength (RSS) on positioning performance. Another work that uses RSS is [30] for wireless localization that can be used in applications where the information whether an object is inside or outside of a specific area is needed only. For more details on localization techniques in IoV and VANET, please refer to the surveys in [43, 44].


## 2.1. Existing Speed-Limit Traffic Violation Recording Systems

The discussions here focus on two key issues: detecting the vehicle’s speed and extracting the official speed-limit information at the current location of the vehicle.Several works for detecting automatic traffic violations use different ways to estimate the speed of the vehicle. In [12], the vehicle speed is estimated using a motion plane-based approach considering the projection displacement difference (PDD). Here, the vehicle reference point is the same as the center of a vehicle license plate and is used to estimate the motion plane. Then, the displacement is estimated by mapping the plate position to the motion plane. Another work that uses customized hardware to estimate the speed is [13], where an array of active infrared sensors is used to report violation-related data to the data center. The work in [14] also uses customized hardware to estimate the speed of the vehicle. In [15], a speedometer using XBee is used to record the vehicle’s speed to compare with the network of Master XBees.The method in [16] uses Road Side Units (RSUs) in a Vehicular Ad Hoc Network (VANET) for estimating vehicular speed. Using information from nearby several RSUs, the speed of the vehicle can be estimated. A similar research proposal for detecting the speed-limit violation using VANET is presented in [17].The work in [18] uses a different approach for detecting traffic violations based on the real-time video feedback of CCTV cameras. The real-time video footage is analyzed to detect traffic violations, including speed-limit violations. Similar work is reported in [19] where IP (Internet Protocol)-enabled cameras are used to monitor the roads to monitor traffic violations. Another work that uses real-time video feedback for traffic monitoring is reported in [20]. In a similar approach, works in [13, 21, 22] explore the use of Unmanned Aerial Vehicle (UAV) for road safety, traffic, and highway infrastructure management.As for the second issue, different traffic violation recording systems use different approaches to extract the speed-limit information at the vehicle’s current location. The work in [23] attempts to detect the roadside signboards for speed-limit information using image processing and then notify the driver about the extracted information. In [15], a network of Master XBees is installed in every locality that can broadcast information about the speed limit of the locality.Different researchers used techniques for the notification and recording of traffic violations. The work in [23] uses Arduino and GPRS to send traffic violation data to the Cloud for processing. In [16], the traffic violation is computed and recorded in the Cloud from the data sent by Road Side Units. In [15], when speed-limit violation is detected (even after warning), the information regarding the vehicle registration number is transmitted to the master XBee installed specifically for the task. This master XBee is connected to the Cloud Server, and traffic data can be accessed from anywhere.


## 2.2. Internet of Vehicles (IoV)

Since this work utilizes the Internet of Vehicles (IoV) (a typical architecture of IoV is given in Figure1), a brief discussion of the key issues in IoV research is presented here. The use of IoV and VANET for Intelligent Transportation Systems has increased a lot in recent years [2, 24]. Due to the nature of its domain, IoV applications need greater data throughput, lower latency, higher security, and massive connectivity [24]. Emerging new applications in IoV requires seamless connectivity, edge, fog, software-defined, and named data network [25]. When deployed in smart cities, IoV applications need large-scale data sensing, collection, information processing, and storage [3].Figure 1
A universal Internet of Vehicles architecture for smart cities [3].A key concern in IoV and VANET is the security issue in the communicated data to/from vehicles. Using conventional cryptographic techniques may affect the performance of delay-sensitive networks such as IoV and VANETs. To overcome this issue, some researchers have proposed RFID (Radio-Frequency Identification) device-based authentication scheme for IoV [2].Another issue is the radio access technologies that are used in IoV applications. The work in [10] discusses reliable and scalable wireless transmissions for the Internet of Vehicles (IoV). With the massive amount of data transmitted in IoV applications, the work in [10] analyzed the performance of Vehicle-to-Vehicle (V2V) beacon broadcasting using random access-based (IEEE 802.11p). The work in [3] proposed a new architecture for the IoV applications in smart cities.The work in [26] studies the applications of machine learning (ML) to handle IoV requirements of ultralow latency, high reliability, high security, and massive connections of the next-generation (6G) network. The goal here is to assist in the evolution of intelligent radio (IR), and self-learning with proactive exploration.


## 2.3. Positioning Techniques

To locate mobile users techniques such as Time Difference of Arrival (TDOA), Enhanced Observed Time Difference of Arrival (E-OTD), Angle of Arrival (AOA), Time of Arrival (TOA), Received Signal Strength (RSS) indication [27], and GPS systems are used [28, 29]. Many of these methods suffer from issues such as security, the need for special types of antennas, highly complex design algorithms, high estimation time, and high cost. Several research attempts are conducted to provide secure location services and location verification to be sure that the vehicle is not cheating its current location [30–32].There are many other methods proposed for estimating the location of vehicles. Visible light-based positioning for IoV is discussed in [33]. The work in [34] proposed the use of nanointegrated devices to provide accurate distance estimation for VANET. The ego-positioning algorithm based on camera for IoV is presented in [35]. Moreover, Doppler-shifted signals to localize a vehicle by using two RSUs are proposed in [28].Several works focus on the relative locations between vehicles. The relative position between vehicles as well as between a vehicle and Road Side Unit (RSU) is studied in [36]. The authors attempted to optimize the nonranging technology such as DVHop algorithm (with chemical reaction optimization) to reduce the error of localization. Similarly, the authors in [37] propose a method to study the behavioral correlation between vehicles to cluster them. Then, deep learning is used to predict the vehicles’ future location distribution. The work in [38] also deals with the noisy observation of the pairwise distance and the angle between vehicles and considers this as a nonlinear optimization problem, which is solved by deep learning models. Another word for relative localization for ground vehicles is [39], where UAV is used for ranging measurements with ground base stations and other UAVs in the round-trip time mode.In [40], the authors take a different approach for correcting the location estimation by a technique called collaborative driving. They try to correct GPS errors of a legacy car if that car encounters a sensor-rich car in a downtown scenario where GPS accuracies can be bad. The authors in [40] report that GPS error for legacy vehicles is reduced from 90% to 30% for sensor-rich vehicles. Another work that deals with correcting the GPS locations is [41]. Here, the authors propose an assistant vehicle localization method based on direction-of-arrival (DOA) estimation to improve the accuracy of vehicle localization. The proposed system is very complex, consisting of a minimum of three multiple-input-multiple-output (MIMO) base stations (BSs). The positions of the three BSs and the DOAs of vehicles estimated by the BSs are used to estimate the locations of the vehicles.The work in [42] deals with users’ location privacy: designing a realistic, privacy-preserving positioning system based on fingerprinting. The work in [27] studies the effect of the Received Signal Strength (RSS) on positioning performance. Another work that uses RSS is [30] for wireless localization that can be used in applications where the information whether an object is inside or outside of a specific area is needed only. For more details on localization techniques in IoV and VANET, please refer to the surveys in [43, 44].


## 3. Overall System Architecture of the Speed-Limit Violation Detection and Reporting Based on IoV

In this section, we present the overall system architecture of the proposed systems for detecting the speed-limit violation and reporting the violations to the authorities using IoV technology. The architecture consists of the basic functional layers of IoV. However, the On-Board Unit (OBU), the Road Side Unit (RSU), and the Cloud Servers (CSs) are to be upgraded (software only). In the next sections, we explain each of the components of the system. We show in Figure2 the abstract IoV architecture focusing on the essential components that will be used in the two systems (presented in the next section) for automatically detecting and reporting the speed-limit violations without any extra hardware.Figure 2
Overall over-/underspeed limit violation detection and reporting system based on the Internet of Vehicles.


### 3.1. The On-Board Unit of the Vehicle

The most elementary module of IoV is the On-Board Unit (OBU) that has to be installed inside each vehicle. The OBU allows the vehicle to communicate with the other components of IoV and to perform IoV operations in the vehicle. We depict in Figure2 the basic OBU as well as the extra modules that are essential to perform the autonomous and automatic speed-limit violation detection and reporting. Each of the modules/units of OBU is described as follows:(a)
Internet of Vehicles (IoV) protocol stack allows the vehicle to communicate securely with other entities and implements all the essential IoV layers.(b)
V2I and V2C communication unit for the Vehicle-to-Infrastructure (RSU) and Vehicle-to-Cloud communication. The communication is bidirectional. Committed traffic violations will be sent to RSU (using V2I), and then RSU will send them to Cloud Servers.(c)
GNSS and location service unit enables the vehicle to obtain in real-time its location, its speed, and its direction in degrees. More details are given in Section 3.5.(d)
Speed-limit violation detection unit implements the algorithm for speed-limit violation detection in the case when OBU is responsible for the detection as described in Section 4.1.(e)
Speed-limit evaluation reporting unit sends committed speed-limit violations to CSs through RSUs.(f)
Driver UI provides visual and vocal messages and directions to drivers. It consists of an interactive touchscreen, microphone, speech recognition engine, and speakers. It produces warning messages and instructions to drivers.(g)
Security and antitampering unit provides the security layers of the components of the OBU. In addition, it provides the privacy of the information of the driver (to avoid tracking the vehicle for example). PKI integrated with the CSs’ Certificate Authority (CA) specialized for IoV is implemented in this unit. It guarantees secure communication with the other entities. In addition, this unit protects OBU from being tampered with or bypassed. For more details about security issues in IoV, please refer to [26, 31, 45–53].


### 3.2. Interconnected Road Side Units (RSUs)

An essential component of IoV is the infrastructure, which consists of Road Side Units (RSUs) that are connected to a dedicated network. This network is connected to CSs and Traffic Management. RSUs are installed alongside roads. In this way, vehicles can communicate with RSU’s using V2I communication. In addition, vehicles can communicate with CSs using RSU as the gateway. As shown in Figure2, an RSU has the following components:(a)
Internet of Vehicles (IoV) protocol stack is required for RSU’s essential functionality. It is different from the stack on an RSU. RSU stack provides functionalities such as V2I, I2C, and RSU to RSU communication.(b)
V2I and I2C communication unit to allow the communication between an RSU and nearby vehicles on a road and to receive the messages from the vehicles and send them to CSs. This unit is essential for the functionality of the “Traffic Violation Detection and Reporting using the RSU,” as described in Section 1.(c)
Speed-limit unit caches the allowed speed limits for each vehicle type. It obtains the speed-limit values from Digital Map Service that runs in CSs. This minimizes the requests to CSs and avoids excessive costs for fetching these values from the Digital Map Service Provider unit. Details about this are given in Section 3.4.(d)
Security and antitampering unit implements the necessary level of security for RSU to allow secure and private communication with all other entities. For more details, please refer to the equivalent unit in the OBU, in Section 3.1.


### 3.3. Cloud Servers (CSs)

One essential component in IoV, which does not exist in VANET, is the Cloud. It consists of several clustered servers running in the Cloud that provide the required services to IoV. The CSs may provide the following services:(a)
Digital Map-Speed Limits. This is the most important service in this paper. More details are given in Section 3.4.(b)
Committed Speed-Limit Violations. This service acts as the database of the committed speed-limit violations for each vehicle. It receives the committed violations from the OBU or calculates them from the data received from RSU (as described in Section 1). For each committed violation, the start time and date of the violation, its duration, the maximum reached value of overspeeding or underspeeding, the location (coordinates, road name, city, and country), the vehicle electronic unique ID, etc. will be saved.(c)
Vehicle Database. It contains all vehicle data, such as electronic ID, driver name, and driver ID. In addition, digital certificates of each vehicle and any other information about the vehicle could be saved in this back-end database.(d)
Dynamic Fine Calculation. This service calculates the violation fines dynamically according to a dynamic policy that can be changed by the traffic authority. It could not be implemented by the existing techniques. Details about this are given in Section 5.(e)
E-Payment Gateway. This service integrates the e-payment methods to allow the automatic payment of the committed fines.(f)
Traffic Authority Control. This service allows the traffic authorities to control and monitor the system, for example, disabling the traffic violation on a specific period of time on a specific road or zone.(g)
Security and Disaster Recovery Layer. It includes all the security measures to secure the services from cybersecurity attacks. It involves backups and disaster recovery as well.


### 3.4. Digital Map Service and the Speed Limits

Another essential component of the proposed systems is the Digital Map Service and Speed-Limit Service providers. This enables the systems and the drivers to know the allowed speed ranges at each location and lane on the road. The speed limits vary according to the vehicle type. Speed limits can also be globally adjusted according to specific conditions, such as weather conditions. For example, RSU can broadcast to all vehicles to reduce the maximum speed limit for small cars to 60 km/hr for a specific road segment, because the IoV infrastructure has detected that it is currently foggy. This component consists of the following units:(a)
Speed limits API. It retrieves the speed-limit information as a function of a coordinate or a road segment. The retrieved data could vary according to the vehicle type, the lane, the time of the day, the weather condition, etc. Upon request from any other component on the system (OBU, RSU, or CSs), the API obtains the data from the Digital Map Service Provider. Details about this are given in Section 3.6.(b)
Road/Lanes API. It provides the lane and road information.(c)
Digital Map Service Provider Selection. It selects the suitable Digital Map Service Provider, if there are more than one. This depends on the policy, the cost, and service agreement.(d)
Speed-Limit Cache Management. Usually, if a third party provides the speed-limit information through their digital maps, the requests are not free, and this costs money. If each vehicle requests a speed-limit query every second while on the road, this means that a large number of requests will be sent to the Digital Map Service Providers. This will cause several problems and can cost too much. To make the system effective and efficient, this module will cache every new response from the service provider. Future requests from the OBU or RSU will be sent directly from the cached information. In addition, when a vehicle queries the system for the speed limits at a location, the OBU of the vehicle saves the returned information in its local storage for future uses. Furthermore, RSUs cache speed limits in their covered areas and broadcast this information to the vehicles. Thus, new requests to the service provider will be minimized. Care must be taken to set a suitable cache duration and to delete outdated cached items. In addition, for specific events, when the authority would like to change the speed limits for a specific time in road segments, then the old entries must be updated by the new one. The Cache Management unit handles all these actions.


### 3.5. Global Navigation Satellite System (GNSS) and Location Service

In IoV, the vehicle must know its current all the time. In addition, the vehicle’s speed is calculated from the temporal change of the vehicle’s location, if access to the CAN bus is not possible. Furthermore, the vehicle’s moving direction (bearing angle) can be calculated from the change of location. Thus, location service is a must for the proper operation of IoV. As stated in Section2.3, there are several location services for IoV. In this section, we will explain the most common ones. The most common one is GPS; however, its accuracy is not enough to allow the vehicle to know on which lane it is moving. As shown in Table 1, GPS provides an accuracy between 2 and 5 meters.Table 1
Accuracy of the common location service types.
Location service typeAverage accuracyRemarksStandard GPS2–5 mNot suitable for critical IoV applications, such as collision warningGlobal navigation satellite system (GNSS)1–2 mMust receive from more than one satellite system and frequenciesDifferential GPS (DGPS)0.3–0.8 mCorrecting base station must be installed and sends real-time error information to surrounding GPS receivers. NTRIP protocol can be used with a subscription through the internetRTK0.01–0.05 mLike DGPS, but using different algorithms, thus providing cm-accuracy, especially when a vehicle is close to a base stationCurrently, there are many GNSS [54] constellations such as GPS [55], BeiDou [56], Galileo [57], and GLONASS [58]. Each satellite system operates on different frequencies, as shown in Figure 3. To improve the accuracy of the location service, the GNSS receiver must receive from two or more satellite systems. This significantly improves the accuracy that can be in the range of 0.7–1.5 meters. For more details on the accuracy of combining two or more different systems, please refer to [60–62].Figure 3
GNSS satellite systems and their frequencies [59].DGPS (Differential GPS) provides an accuracy of about 1–2 meters. It consists of installing a ground station that can calculate the real-time errors in the signals and broadcasts them to the surrounding vehicles. Similar to DGPS, RTK (Real-Time Kinematic) relays on a ground station to calculate the GNSS errors at its surrounding, as shown in Figure4. One great advantage of RTK is that it can provide an accuracy of few centimeters (2–5 cm). Table 1 shows a comparison of the accuracy of the different positioning systems that can be used in IoV.Figure 4
RTK (Real-Time Kinematic) for providing accurate positioning system and correcting the GNSS errors [63].


### 3.6. On the Digital Map Service Provider and the Speed-Limit Retrieval

Digital maps are essential components of the system. We need them to determine many parameters: the location of the committed violation and the allowed speed limit, etc. In the following, we discuss several digital map services available for research and development.


#### 3.6.1. OpenStreetMaps

OpenStreetMap data can be used to extract the maximum speed limits and the number of lanes, etc. However, these map data are not available for all the countries.


#### 3.6.2. Google Maps

Google Maps is a web mapping service developed by Google and launched in February 2005.“The Roads API” returns the maximum speed limit for a given road coordinate on a road. However, the reported speed limits are not accurate, and the service is not available in many countries.


#### 3.6.3. Sygic Digital Maps

Sygic navigation provides real-time traffic information based on TomTom Traffic. Sygic has a “Road info” API which is a Cloud-based service that can return the speed limits about the selected road or road segments.However, we tested this service while driving on many roads in Saudi Arabia. However, the returned speed limits were not accurate and were outdated.


#### 3.6.4. TomTom Digital Maps

This service is similar to Sygic; however, the service cost is high. For more information, please refer to the site:https://developer.tomtom.com/store/maps-api.


#### 3.6.5. MS Bing Digital Maps

Microsoft Bing Maps is a web application with custom maps. There is a fee for providing the speed limit.The Snap-to-Road API is a convenient REST service for this research work. Bing Maps Snap-to-Road API needs GPS points (latitude and longitude coordinates) in a URL and returns a corresponding set of data with the points that snap to the most likely roads and corresponding road names and the speed limits. This service provides accurate and updated information about the speed limit in many different countries. It is one of the best available speed-limit services suitable to our proposed systems.


#### 3.6.6. HERE Technologies

HERE Technologies (here.com) is one of the leaders in location technologies. They have the most accurate and updated database and the most extensive coverage of the speed-limit information. The cost of the service is cheap, and they provide free monthly service access that is enough for testing and validation. We have integrated this service into our developed software and systems.


### 3.7. Security Considerations

An important concern about the applicability of the proposed systems is the security issues that may include hardware tampering, software tampering, and information security. IoV security issues are extensively studied in the literature. Our proposed systems use the same IoV security approaches. We will focus here on the security issues related to the functionality of the speed-limit violation detection and reporting application only. The Root of Trust is a very effective approach for securing the hardware of all the components of the system. Thus, it can be used to effectively secure OBU from any hardware tampering and program the vehicle system to not start if any violation of the hardware or software integrity is detected. Secure software development is a must for such systems, and it must be done by a trusted authority with software signing by their digital certificate. Thus, any tampering of the software can be detected and hence stop the engine of the vehicle. Only these software authorities can update or upgrade the OBU, RSU, and CS software. The users/drivers cannot have access to update the software on RSU and thus cannot stop the traffic violation detection or reporting when the violation detection and reporting are done by OBU. For the case when RSU and CS are used to detect and report speed-limit traffic violations, there is no security issue, as they will be maintained only by the traffic authority. A lot of research works deal with the issue to ensure that a vehicle is broadcasting its real location and speed information.


## 3.1. The On-Board Unit of the Vehicle

The most elementary module of IoV is the On-Board Unit (OBU) that has to be installed inside each vehicle. The OBU allows the vehicle to communicate with the other components of IoV and to perform IoV operations in the vehicle. We depict in Figure2 the basic OBU as well as the extra modules that are essential to perform the autonomous and automatic speed-limit violation detection and reporting. Each of the modules/units of OBU is described as follows:(a)
Internet of Vehicles (IoV) protocol stack allows the vehicle to communicate securely with other entities and implements all the essential IoV layers.(b)
V2I and V2C communication unit for the Vehicle-to-Infrastructure (RSU) and Vehicle-to-Cloud communication. The communication is bidirectional. Committed traffic violations will be sent to RSU (using V2I), and then RSU will send them to Cloud Servers.(c)
GNSS and location service unit enables the vehicle to obtain in real-time its location, its speed, and its direction in degrees. More details are given in Section 3.5.(d)
Speed-limit violation detection unit implements the algorithm for speed-limit violation detection in the case when OBU is responsible for the detection as described in Section 4.1.(e)
Speed-limit evaluation reporting unit sends committed speed-limit violations to CSs through RSUs.(f)
Driver UI provides visual and vocal messages and directions to drivers. It consists of an interactive touchscreen, microphone, speech recognition engine, and speakers. It produces warning messages and instructions to drivers.(g)
Security and antitampering unit provides the security layers of the components of the OBU. In addition, it provides the privacy of the information of the driver (to avoid tracking the vehicle for example). PKI integrated with the CSs’ Certificate Authority (CA) specialized for IoV is implemented in this unit. It guarantees secure communication with the other entities. In addition, this unit protects OBU from being tampered with or bypassed. For more details about security issues in IoV, please refer to [26, 31, 45–53].


## 3.2. Interconnected Road Side Units (RSUs)

An essential component of IoV is the infrastructure, which consists of Road Side Units (RSUs) that are connected to a dedicated network. This network is connected to CSs and Traffic Management. RSUs are installed alongside roads. In this way, vehicles can communicate with RSU’s using V2I communication. In addition, vehicles can communicate with CSs using RSU as the gateway. As shown in Figure2, an RSU has the following components:(a)
Internet of Vehicles (IoV) protocol stack is required for RSU’s essential functionality. It is different from the stack on an RSU. RSU stack provides functionalities such as V2I, I2C, and RSU to RSU communication.(b)
V2I and I2C communication unit to allow the communication between an RSU and nearby vehicles on a road and to receive the messages from the vehicles and send them to CSs. This unit is essential for the functionality of the “Traffic Violation Detection and Reporting using the RSU,” as described in Section 1.(c)
Speed-limit unit caches the allowed speed limits for each vehicle type. It obtains the speed-limit values from Digital Map Service that runs in CSs. This minimizes the requests to CSs and avoids excessive costs for fetching these values from the Digital Map Service Provider unit. Details about this are given in Section 3.4.(d)
Security and antitampering unit implements the necessary level of security for RSU to allow secure and private communication with all other entities. For more details, please refer to the equivalent unit in the OBU, in Section 3.1.


## 3.3. Cloud Servers (CSs)

One essential component in IoV, which does not exist in VANET, is the Cloud. It consists of several clustered servers running in the Cloud that provide the required services to IoV. The CSs may provide the following services:(a)
Digital Map-Speed Limits. This is the most important service in this paper. More details are given in Section 3.4.(b)
Committed Speed-Limit Violations. This service acts as the database of the committed speed-limit violations for each vehicle. It receives the committed violations from the OBU or calculates them from the data received from RSU (as described in Section 1). For each committed violation, the start time and date of the violation, its duration, the maximum reached value of overspeeding or underspeeding, the location (coordinates, road name, city, and country), the vehicle electronic unique ID, etc. will be saved.(c)
Vehicle Database. It contains all vehicle data, such as electronic ID, driver name, and driver ID. In addition, digital certificates of each vehicle and any other information about the vehicle could be saved in this back-end database.(d)
Dynamic Fine Calculation. This service calculates the violation fines dynamically according to a dynamic policy that can be changed by the traffic authority. It could not be implemented by the existing techniques. Details about this are given in Section 5.(e)
E-Payment Gateway. This service integrates the e-payment methods to allow the automatic payment of the committed fines.(f)
Traffic Authority Control. This service allows the traffic authorities to control and monitor the system, for example, disabling the traffic violation on a specific period of time on a specific road or zone.(g)
Security and Disaster Recovery Layer. It includes all the security measures to secure the services from cybersecurity attacks. It involves backups and disaster recovery as well.


## 3.4. Digital Map Service and the Speed Limits

Another essential component of the proposed systems is the Digital Map Service and Speed-Limit Service providers. This enables the systems and the drivers to know the allowed speed ranges at each location and lane on the road. The speed limits vary according to the vehicle type. Speed limits can also be globally adjusted according to specific conditions, such as weather conditions. For example, RSU can broadcast to all vehicles to reduce the maximum speed limit for small cars to 60 km/hr for a specific road segment, because the IoV infrastructure has detected that it is currently foggy. This component consists of the following units:(a)
Speed limits API. It retrieves the speed-limit information as a function of a coordinate or a road segment. The retrieved data could vary according to the vehicle type, the lane, the time of the day, the weather condition, etc. Upon request from any other component on the system (OBU, RSU, or CSs), the API obtains the data from the Digital Map Service Provider. Details about this are given in Section 3.6.(b)
Road/Lanes API. It provides the lane and road information.(c)
Digital Map Service Provider Selection. It selects the suitable Digital Map Service Provider, if there are more than one. This depends on the policy, the cost, and service agreement.(d)
Speed-Limit Cache Management. Usually, if a third party provides the speed-limit information through their digital maps, the requests are not free, and this costs money. If each vehicle requests a speed-limit query every second while on the road, this means that a large number of requests will be sent to the Digital Map Service Providers. This will cause several problems and can cost too much. To make the system effective and efficient, this module will cache every new response from the service provider. Future requests from the OBU or RSU will be sent directly from the cached information. In addition, when a vehicle queries the system for the speed limits at a location, the OBU of the vehicle saves the returned information in its local storage for future uses. Furthermore, RSUs cache speed limits in their covered areas and broadcast this information to the vehicles. Thus, new requests to the service provider will be minimized. Care must be taken to set a suitable cache duration and to delete outdated cached items. In addition, for specific events, when the authority would like to change the speed limits for a specific time in road segments, then the old entries must be updated by the new one. The Cache Management unit handles all these actions.


## 3.5. Global Navigation Satellite System (GNSS) and Location Service

In IoV, the vehicle must know its current all the time. In addition, the vehicle’s speed is calculated from the temporal change of the vehicle’s location, if access to the CAN bus is not possible. Furthermore, the vehicle’s moving direction (bearing angle) can be calculated from the change of location. Thus, location service is a must for the proper operation of IoV. As stated in Section2.3, there are several location services for IoV. In this section, we will explain the most common ones. The most common one is GPS; however, its accuracy is not enough to allow the vehicle to know on which lane it is moving. As shown in Table 1, GPS provides an accuracy between 2 and 5 meters.Table 1
Accuracy of the common location service types.
Location service typeAverage accuracyRemarksStandard GPS2–5 mNot suitable for critical IoV applications, such as collision warningGlobal navigation satellite system (GNSS)1–2 mMust receive from more than one satellite system and frequenciesDifferential GPS (DGPS)0.3–0.8 mCorrecting base station must be installed and sends real-time error information to surrounding GPS receivers. NTRIP protocol can be used with a subscription through the internetRTK0.01–0.05 mLike DGPS, but using different algorithms, thus providing cm-accuracy, especially when a vehicle is close to a base stationCurrently, there are many GNSS [54] constellations such as GPS [55], BeiDou [56], Galileo [57], and GLONASS [58]. Each satellite system operates on different frequencies, as shown in Figure 3. To improve the accuracy of the location service, the GNSS receiver must receive from two or more satellite systems. This significantly improves the accuracy that can be in the range of 0.7–1.5 meters. For more details on the accuracy of combining two or more different systems, please refer to [60–62].Figure 3
GNSS satellite systems and their frequencies [59].DGPS (Differential GPS) provides an accuracy of about 1–2 meters. It consists of installing a ground station that can calculate the real-time errors in the signals and broadcasts them to the surrounding vehicles. Similar to DGPS, RTK (Real-Time Kinematic) relays on a ground station to calculate the GNSS errors at its surrounding, as shown in Figure4. One great advantage of RTK is that it can provide an accuracy of few centimeters (2–5 cm). Table 1 shows a comparison of the accuracy of the different positioning systems that can be used in IoV.Figure 4
RTK (Real-Time Kinematic) for providing accurate positioning system and correcting the GNSS errors [63].


## 3.6. On the Digital Map Service Provider and the Speed-Limit Retrieval

Digital maps are essential components of the system. We need them to determine many parameters: the location of the committed violation and the allowed speed limit, etc. In the following, we discuss several digital map services available for research and development.


### 3.6.1. OpenStreetMaps

OpenStreetMap data can be used to extract the maximum speed limits and the number of lanes, etc. However, these map data are not available for all the countries.


### 3.6.2. Google Maps

Google Maps is a web mapping service developed by Google and launched in February 2005.“The Roads API” returns the maximum speed limit for a given road coordinate on a road. However, the reported speed limits are not accurate, and the service is not available in many countries.


### 3.6.3. Sygic Digital Maps

Sygic navigation provides real-time traffic information based on TomTom Traffic. Sygic has a “Road info” API which is a Cloud-based service that can return the speed limits about the selected road or road segments.However, we tested this service while driving on many roads in Saudi Arabia. However, the returned speed limits were not accurate and were outdated.


### 3.6.4. TomTom Digital Maps

This service is similar to Sygic; however, the service cost is high. For more information, please refer to the site:https://developer.tomtom.com/store/maps-api.


### 3.6.5. MS Bing Digital Maps

Microsoft Bing Maps is a web application with custom maps. There is a fee for providing the speed limit.The Snap-to-Road API is a convenient REST service for this research work. Bing Maps Snap-to-Road API needs GPS points (latitude and longitude coordinates) in a URL and returns a corresponding set of data with the points that snap to the most likely roads and corresponding road names and the speed limits. This service provides accurate and updated information about the speed limit in many different countries. It is one of the best available speed-limit services suitable to our proposed systems.


### 3.6.6. HERE Technologies

HERE Technologies (here.com) is one of the leaders in location technologies. They have the most accurate and updated database and the most extensive coverage of the speed-limit information. The cost of the service is cheap, and they provide free monthly service access that is enough for testing and validation. We have integrated this service into our developed software and systems.


## 3.6.1. OpenStreetMaps

OpenStreetMap data can be used to extract the maximum speed limits and the number of lanes, etc. However, these map data are not available for all the countries.


## 3.6.2. Google Maps

Google Maps is a web mapping service developed by Google and launched in February 2005.“The Roads API” returns the maximum speed limit for a given road coordinate on a road. However, the reported speed limits are not accurate, and the service is not available in many countries.


## 3.6.3. Sygic Digital Maps

Sygic navigation provides real-time traffic information based on TomTom Traffic. Sygic has a “Road info” API which is a Cloud-based service that can return the speed limits about the selected road or road segments.However, we tested this service while driving on many roads in Saudi Arabia. However, the returned speed limits were not accurate and were outdated.


## 3.6.4. TomTom Digital Maps

This service is similar to Sygic; however, the service cost is high. For more information, please refer to the site:https://developer.tomtom.com/store/maps-api.


## 3.6.5. MS Bing Digital Maps

Microsoft Bing Maps is a web application with custom maps. There is a fee for providing the speed limit.The Snap-to-Road API is a convenient REST service for this research work. Bing Maps Snap-to-Road API needs GPS points (latitude and longitude coordinates) in a URL and returns a corresponding set of data with the points that snap to the most likely roads and corresponding road names and the speed limits. This service provides accurate and updated information about the speed limit in many different countries. It is one of the best available speed-limit services suitable to our proposed systems.


## 3.6.6. HERE Technologies

HERE Technologies (here.com) is one of the leaders in location technologies. They have the most accurate and updated database and the most extensive coverage of the speed-limit information. The cost of the service is cheap, and they provide free monthly service access that is enough for testing and validation. We have integrated this service into our developed software and systems.


## 3.7. Security Considerations

An important concern about the applicability of the proposed systems is the security issues that may include hardware tampering, software tampering, and information security. IoV security issues are extensively studied in the literature. Our proposed systems use the same IoV security approaches. We will focus here on the security issues related to the functionality of the speed-limit violation detection and reporting application only. The Root of Trust is a very effective approach for securing the hardware of all the components of the system. Thus, it can be used to effectively secure OBU from any hardware tampering and program the vehicle system to not start if any violation of the hardware or software integrity is detected. Secure software development is a must for such systems, and it must be done by a trusted authority with software signing by their digital certificate. Thus, any tampering of the software can be detected and hence stop the engine of the vehicle. Only these software authorities can update or upgrade the OBU, RSU, and CS software. The users/drivers cannot have access to update the software on RSU and thus cannot stop the traffic violation detection or reporting when the violation detection and reporting are done by OBU. For the case when RSU and CS are used to detect and report speed-limit traffic violations, there is no security issue, as they will be maintained only by the traffic authority. A lot of research works deal with the issue to ensure that a vehicle is broadcasting its real location and speed information.


## 4. Proposed Systems for Speed-Limit Violation Detection and Reporting Using IoV

In this section, we present two smart systems that can effectively detect the speed-limit (overspeeding or underspeeding) violation and automatically report them based on IoV technology. The first one will be using the OBU of the vehicle itself. The second one is a centralized system that uses broadcast messages from vehicles and involves the use of RSU and CSs to be able to determine the violation of any vehicle anywhere in the city. In addition, a dynamic and adaptive traffic fine calculation policy is proposed.


### 4.1. OBU-Only System for Violation Detection and Reporting

The vehicle is the first object that knows its speed in real-time at any time. It can know its speed from the CAN bus. In addition, the OBU of the vehicle can know the temporal change of the location of the vehicle from the GNSS or any other reliable location service. Thus, the vehicle’s OBU can calculate the speed of the vehicle in real-time. In addition, as described in Section3.4, the vehicle according to its current location, its type, and the lane on the road can know the allowed speed limits from the “Digital Map Service and the Speed Limits” component of IoV. These are the only needed information to be able to detect if the vehicle is moving within the allowed limits or violating the speed limits. Thus, why not updating the OBU software of the vehicle in order to detect any speed-limit violation anytime, anywhere without adding any extra hardware to the IoV architecture? Additionally, why not reporting these committed speed-limit violations by the vehicle’s OBU to the traffic authority for collecting fines or taking legal actions according to the traffic rules and regulations. Traditionally, it is not logical that the vehicle detects and reports the violations it commits, but using IoV, this could be possible and this would provide many advantages compared to the existing techniques.One challenge of this system is because the OBU is installed on the vehicle; thus, it could be tampered to disable the reporting feature. However, there are intensive research efforts in securing both the hardware and the software of IoV components (all the building blocks). Thus, any tampering of any components, including the OBU, can be easily detected, and the vehicle will stop and not start. For more details, please refer to Section3.7.In this section, we present how the OBU of the vehicle can detect and report the speed-limit violations in the context of IoV. The algorithm is presented in detail in listing Algorithm1. A simplified flowchart for this algorithm is shown in Figure 5. In brief, the overall algorithm can be summarized as follows: the OBU obtains its current location, then it obtains or calculates its current speed, next it obtains the allowed speed limits, then it compares the current speed with the allowed one, then it records the violation if occurred, and finally, it reports the violations.Algorithm 1: Overspeed limit violation detection and reporting using the On-Board Unit (OBU) of the vehicle.
(1)
Obtain the current speed, Current_Speed, of the vehicle depending on the following methods.(a)If there is access to the internal computer of the vehicle using CAN bus protocol, then obtain the current speed of the vehicle using the CAN bus decoding hardware. This is the most accurate and preferable method as the speed is available all the time even if the GNSS signal cannot be received from any satellite constellation.(b)Else if GNSS signal can be received from at least one satellite constellation system, use the GNSS receiver of the OBU to calculate the current speed.(i)If no error-correcting service is available, then decrease the value of the current speed by a safety value to compensate for the errors in the GNSS accuracy, for example, 5 km/s.(c)Else If the GNSS signal is very week and the GNSS receiver cannot receive from at least one satellite system, then the current speed is invalid and the traffic violation cannot be obtained, and skip the remaining steps.(2)
Obtain the current location coordinate, Current_Location, of the vehicle using the GNSS module in the On-Board Unit (OBU). For more details, please refer to Section 3.5.(3)
Obtain the maximum allowed speed limit,Maximum_Allowed_Speed_Limit for this Current_Location on the road, the Vehicle_Type, the Current_Lane, and the Weather_Condition as follows.(a)If the information is cached in the internal memory of the OBU (requested previously or received from any Road Side Unit or CSs), then use the maximum allowed speed limit saved previously.(b)Else if there is a nearby Road Side Unit, request the maximum allowed speed limit from it and save it in the internal memory.(c)Otherwise, use the Internet access to reach directly the CSs to request the Maximum_Allowed_Speed_Limit and save it in the internal memory. The “Digital Map-Speed Limit” service executes the following:(i)If the location is stored in the System Database, respond with the maximum speed limit for this location.(ii)Otherwise, do a REST request to “Digital Map Service Provider” to obtain the maximum speed limit for this location, save it in the System Database, and respond back to the requesting vehicle. This is the only payable request. All the other requests are free as they are all saved inside the different modules of the entire system. For more details, please refer to Section 3.4.(4)
If the Current_Speed > Maximum_Allowed_Speed_Limit,then an overspeed limit violation occurred, do the following:(a)Warn (vocally and visually) the driver that he/she is committing a speed-limit violation. According to the traffic authority regulations, it could be allowed to overspeed for few seconds without recording a violation (for example, to overtake a slow vehicle). This is completely possible with our approach.(b)Record in the internal memory of the OBU an Over_Speed_Limit violation event. Record also the current time as the start time.(c)Record the Current_Location, the road information from the digital map, Maximum_Allowed_Speed_Limit (important in a case of future modification of this value by the traffic authority).(d)Calculate the maximum reached speed and the duration of the overspeeding as follows:(i)Set the Maximum_Excess_Speed = Current_Speed-Maximum_Allowed_Speed_Limit.(ii)While Maximum_Allowed_Speed_Limit < Current_Speed.(1)Wait for a specific time, for example, 20 seconds(2)Recalculate the Current_Speed from step 1(3)If (Current_Speed-Maximum_Allowed_Speed_Limit) > Maximum_Excess_Speed, then set Maximum_Excess_Speed = Current_Speed-Maximum_Allowed_Speed_Limit(iii)Now, the speed violation ends, thus, record the current time as the violation end time and the Maximum_Excess_Speed in that violation. This is essential as the fines depend mainly on this value.(e)Report the committed violation as follows:(i)If there is connectivity to a nearby RSU, then send the violation details to it. The RSU then sends the violation details to the CSs.(ii)Else if there is Internet access to the CSs, then send the violation details directly to them.(ii)Otherwise, wait until any available connectivity is available and sends the violation.(iii) An “Acknowledgment message” must be sent back from the Cloud Server to the OBU that the violation is successfully reported in order to flag the violation as reported.(5)
Wait for a predefined time (set globally in the whole system, e.g., 20 seconds) and then repeat the whole process to periodically check if the vehicle is overspeeding.Figure 5
Flowchart of overspeeding violation detection using the OBU (simplified flowchart of Algorithm1).In some countries, if a vehicle is moving at a very low speed beyond the minimum allowed speed limit, it is considered as another kind of traffic violation. This is because underspeeding can also cause accidents and traffic congestions. The previous algorithm can be slightly modified to detect and report this kind of violation, as explained in Algorithm2. A simplified flowchart for this algorithm is shown in Figure 6.Algorithm 2: Underspeed limit violation detection and reporting using the On-Board Unit (OBU) of the vehicle.
(1)
Obtain the current speed, Current_Speed, of the vehicle depending on the following methods as in step #1 of Algorithm 1, except in step 1b).(i)If no error-correcting service is available, thenincrease the value of the current speed by a safety value to compensate for the errors in the GNSS accuracy, for example, 5 km/s.(2)
Obtain the current location coordinate, Current_Location as step #2 of Algorithm 1.(3)
Obtain the minimum allowed speed limit,Minimum_Allowed_Speed_Limit for this Current_Location on the road, the Vehicle_Type, the Current_Lane, and the Weather_Condition as given in step #3 of Algorithm 1.(4)
If the Current_Speed < Minimum_Allowed_Speed_Limit,then an underspeed limit violation occurred, do the following:(a)Record in the internal memory of the OBU an Under_Speed_Limit violation event. Record also the current time as the start time.(b)Record the Current_Location, the road information from the digital map, Minimum_Allowed_Speed_Limit (important in a case of future modification of this value by the traffic authority).(c)Calculate the maximum underspeeding value and the duration of the underspeeding as follows:(i)Set the Maximum_Under_Speed = Minimum_Allowed_Speed_Limit-Current_Speed.(ii)While Current_Speed < Minimum_Allowed_Speed_Limit.(1)Wait for a specific time, for example, 20 seconds(2)Recalculate the Current_Speed from step 1(3)If (Minimum_Allowed_Speed_Limit - Current_Speed) > Maximum_Under_Speed, then set Maximum_Under_Speed = Minimum_Allowed_Speed_Limit-Current_Speed(iii)Now, the speed violation ends, and thus, record the current time as the violation end time and the Maximum_Under_Speed in that violation. This is essential as the fines depend mainly on this value.(e)Report the committed violation as step #4d in Algorithm 1.(5)
Wait for a predefined time as in Algorithm 1.Figure 6
Flowchart of underspeeding violation detection using the OBU (simplified flowchart of Algorithm2).


### 4.2. Speed-Limit Violation Detection and Reporting Using the RSU and the CSs

In this section, we present a different system that detects and reports speed-limit violations. In the previous section, we presented a system that uses only the OBU of the vehicle to autonomously detect and report the speed limit violations without support from the RSU or the CSs. In this section, another system is proposed. In this system, the detection and reporting are carried out by the OBU of the vehicle, the road-side units (RSUs), and the cloud servers (CSs). The rationales behind this approach are as follows. Each vehicle periodically broadcasts its current location to the infrastructure using Vehicle-to-Infrastructure (V2I) messages. These messages are received by nearby RSU(s). These messages contain the timestamp, the vehicle’s current location, and other information that is used for other purposes. In the case when the detection and reporting are to be done on CSs, but not by the vehicle only, we have two cases.


#### 4.2.1. When Vehicles Broadcast Their Real-Time Speed

If a vehicle is broadcasting its real-time speed, then RSUs will receive these messages. Each RSU will encapsulate the received messages and sends them to CSs. The encapsulated messages contain the RSU ID. Thus, CSs can know the rated speed limits for the area covered by that RSU. The CSs will have for each vehicle the vehicle speed and the allowed speed limits as a function of time (the timestamp of each V2I message). CSs compare the allowed speed limits with each vehicle to know if the vehicle is violating the speed limit or not. The challenge here is to obtain the duration of the over-/underspeeding and the maximum/minimum reached speeds. CSs can easily determine if a vehicle is violating or not. In the case of a violation, CSs can obtain all the details of the violation (start time, duration, peak speed, location, etc.) from the available data. This can be done by slightly modifying Algorithm1, as given in the previous section.


#### 4.2.2. When Vehicles Broadcast Their Temporal Locations Only

The minimum information to be sent from a vehicle to RSU is the vehicle’s temporal location. If a vehicle is not broadcasting its real-time speed, then the vehicle’s temporal location is enough to calculate the speed as a function of time. Similar to what is described in Section4.2.1, an RSU receives messages broadcasted from vehicles and encapsulates the messages and resends them to CSs. CSs calculate the temporal speed for a vehicle from temporal locations of the vehicle, then continue the processing following the same way as described in Section 4.2.1.To calculate the temporal speed from the temporal location, the following approach is used.For a given vehicle, for two consecutive broadcast messagesmi−1, mi, the vehicle at time ti−1 where at location Ri−1, then at time ti, it moved to location Pi, where Pi and Ri−1 are represented by latitude α and the longitude β in degrees. The distance between the two locations dPi,Pi−1 can be obtained by Haversine’s formula [64]. It is used to obtain the shortest distance between two points over the Earth’s surface as follows:(1)dRi,Ri−1=ℛ∗c,where ℛ is the radius of the Earth (mean radius = 6,371 km), where c=2∗atan2a,1−a, where a = sin2 (π(αi − αi−1)/360) + cos (παi/180) ∗ cos (παi−1/180) ∗ sin2 (π (βi − βi−1)/360).We can obtain the temporal speed of the vehicle as follows:(2)vi=dRi,Ri−1ti−ti−1.The CS can determine the start, duration, maximum/minimum speed, and location of any speed-limit violation committed by any vehicle from the temporal speed information according to Algorithm1.


## 4.1. OBU-Only System for Violation Detection and Reporting

The vehicle is the first object that knows its speed in real-time at any time. It can know its speed from the CAN bus. In addition, the OBU of the vehicle can know the temporal change of the location of the vehicle from the GNSS or any other reliable location service. Thus, the vehicle’s OBU can calculate the speed of the vehicle in real-time. In addition, as described in Section3.4, the vehicle according to its current location, its type, and the lane on the road can know the allowed speed limits from the “Digital Map Service and the Speed Limits” component of IoV. These are the only needed information to be able to detect if the vehicle is moving within the allowed limits or violating the speed limits. Thus, why not updating the OBU software of the vehicle in order to detect any speed-limit violation anytime, anywhere without adding any extra hardware to the IoV architecture? Additionally, why not reporting these committed speed-limit violations by the vehicle’s OBU to the traffic authority for collecting fines or taking legal actions according to the traffic rules and regulations. Traditionally, it is not logical that the vehicle detects and reports the violations it commits, but using IoV, this could be possible and this would provide many advantages compared to the existing techniques.One challenge of this system is because the OBU is installed on the vehicle; thus, it could be tampered to disable the reporting feature. However, there are intensive research efforts in securing both the hardware and the software of IoV components (all the building blocks). Thus, any tampering of any components, including the OBU, can be easily detected, and the vehicle will stop and not start. For more details, please refer to Section3.7.In this section, we present how the OBU of the vehicle can detect and report the speed-limit violations in the context of IoV. The algorithm is presented in detail in listing Algorithm1. A simplified flowchart for this algorithm is shown in Figure 5. In brief, the overall algorithm can be summarized as follows: the OBU obtains its current location, then it obtains or calculates its current speed, next it obtains the allowed speed limits, then it compares the current speed with the allowed one, then it records the violation if occurred, and finally, it reports the violations.Algorithm 1: Overspeed limit violation detection and reporting using the On-Board Unit (OBU) of the vehicle.
(1)
Obtain the current speed, Current_Speed, of the vehicle depending on the following methods.(a)If there is access to the internal computer of the vehicle using CAN bus protocol, then obtain the current speed of the vehicle using the CAN bus decoding hardware. This is the most accurate and preferable method as the speed is available all the time even if the GNSS signal cannot be received from any satellite constellation.(b)Else if GNSS signal can be received from at least one satellite constellation system, use the GNSS receiver of the OBU to calculate the current speed.(i)If no error-correcting service is available, then decrease the value of the current speed by a safety value to compensate for the errors in the GNSS accuracy, for example, 5 km/s.(c)Else If the GNSS signal is very week and the GNSS receiver cannot receive from at least one satellite system, then the current speed is invalid and the traffic violation cannot be obtained, and skip the remaining steps.(2)
Obtain the current location coordinate, Current_Location, of the vehicle using the GNSS module in the On-Board Unit (OBU). For more details, please refer to Section 3.5.(3)
Obtain the maximum allowed speed limit,Maximum_Allowed_Speed_Limit for this Current_Location on the road, the Vehicle_Type, the Current_Lane, and the Weather_Condition as follows.(a)If the information is cached in the internal memory of the OBU (requested previously or received from any Road Side Unit or CSs), then use the maximum allowed speed limit saved previously.(b)Else if there is a nearby Road Side Unit, request the maximum allowed speed limit from it and save it in the internal memory.(c)Otherwise, use the Internet access to reach directly the CSs to request the Maximum_Allowed_Speed_Limit and save it in the internal memory. The “Digital Map-Speed Limit” service executes the following:(i)If the location is stored in the System Database, respond with the maximum speed limit for this location.(ii)Otherwise, do a REST request to “Digital Map Service Provider” to obtain the maximum speed limit for this location, save it in the System Database, and respond back to the requesting vehicle. This is the only payable request. All the other requests are free as they are all saved inside the different modules of the entire system. For more details, please refer to Section 3.4.(4)
If the Current_Speed > Maximum_Allowed_Speed_Limit,then an overspeed limit violation occurred, do the following:(a)Warn (vocally and visually) the driver that he/she is committing a speed-limit violation. According to the traffic authority regulations, it could be allowed to overspeed for few seconds without recording a violation (for example, to overtake a slow vehicle). This is completely possible with our approach.(b)Record in the internal memory of the OBU an Over_Speed_Limit violation event. Record also the current time as the start time.(c)Record the Current_Location, the road information from the digital map, Maximum_Allowed_Speed_Limit (important in a case of future modification of this value by the traffic authority).(d)Calculate the maximum reached speed and the duration of the overspeeding as follows:(i)Set the Maximum_Excess_Speed = Current_Speed-Maximum_Allowed_Speed_Limit.(ii)While Maximum_Allowed_Speed_Limit < Current_Speed.(1)Wait for a specific time, for example, 20 seconds(2)Recalculate the Current_Speed from step 1(3)If (Current_Speed-Maximum_Allowed_Speed_Limit) > Maximum_Excess_Speed, then set Maximum_Excess_Speed = Current_Speed-Maximum_Allowed_Speed_Limit(iii)Now, the speed violation ends, thus, record the current time as the violation end time and the Maximum_Excess_Speed in that violation. This is essential as the fines depend mainly on this value.(e)Report the committed violation as follows:(i)If there is connectivity to a nearby RSU, then send the violation details to it. The RSU then sends the violation details to the CSs.(ii)Else if there is Internet access to the CSs, then send the violation details directly to them.(ii)Otherwise, wait until any available connectivity is available and sends the violation.(iii) An “Acknowledgment message” must be sent back from the Cloud Server to the OBU that the violation is successfully reported in order to flag the violation as reported.(5)
Wait for a predefined time (set globally in the whole system, e.g., 20 seconds) and then repeat the whole process to periodically check if the vehicle is overspeeding.Figure 5
Flowchart of overspeeding violation detection using the OBU (simplified flowchart of Algorithm1).In some countries, if a vehicle is moving at a very low speed beyond the minimum allowed speed limit, it is considered as another kind of traffic violation. This is because underspeeding can also cause accidents and traffic congestions. The previous algorithm can be slightly modified to detect and report this kind of violation, as explained in Algorithm2. A simplified flowchart for this algorithm is shown in Figure 6.Algorithm 2: Underspeed limit violation detection and reporting using the On-Board Unit (OBU) of the vehicle.
(1)
Obtain the current speed, Current_Speed, of the vehicle depending on the following methods as in step #1 of Algorithm 1, except in step 1b).(i)If no error-correcting service is available, thenincrease the value of the current speed by a safety value to compensate for the errors in the GNSS accuracy, for example, 5 km/s.(2)
Obtain the current location coordinate, Current_Location as step #2 of Algorithm 1.(3)
Obtain the minimum allowed speed limit,Minimum_Allowed_Speed_Limit for this Current_Location on the road, the Vehicle_Type, the Current_Lane, and the Weather_Condition as given in step #3 of Algorithm 1.(4)
If the Current_Speed < Minimum_Allowed_Speed_Limit,then an underspeed limit violation occurred, do the following:(a)Record in the internal memory of the OBU an Under_Speed_Limit violation event. Record also the current time as the start time.(b)Record the Current_Location, the road information from the digital map, Minimum_Allowed_Speed_Limit (important in a case of future modification of this value by the traffic authority).(c)Calculate the maximum underspeeding value and the duration of the underspeeding as follows:(i)Set the Maximum_Under_Speed = Minimum_Allowed_Speed_Limit-Current_Speed.(ii)While Current_Speed < Minimum_Allowed_Speed_Limit.(1)Wait for a specific time, for example, 20 seconds(2)Recalculate the Current_Speed from step 1(3)If (Minimum_Allowed_Speed_Limit - Current_Speed) > Maximum_Under_Speed, then set Maximum_Under_Speed = Minimum_Allowed_Speed_Limit-Current_Speed(iii)Now, the speed violation ends, and thus, record the current time as the violation end time and the Maximum_Under_Speed in that violation. This is essential as the fines depend mainly on this value.(e)Report the committed violation as step #4d in Algorithm 1.(5)
Wait for a predefined time as in Algorithm 1.Figure 6
Flowchart of underspeeding violation detection using the OBU (simplified flowchart of Algorithm2).


## 4.2. Speed-Limit Violation Detection and Reporting Using the RSU and the CSs

In this section, we present a different system that detects and reports speed-limit violations. In the previous section, we presented a system that uses only the OBU of the vehicle to autonomously detect and report the speed limit violations without support from the RSU or the CSs. In this section, another system is proposed. In this system, the detection and reporting are carried out by the OBU of the vehicle, the road-side units (RSUs), and the cloud servers (CSs). The rationales behind this approach are as follows. Each vehicle periodically broadcasts its current location to the infrastructure using Vehicle-to-Infrastructure (V2I) messages. These messages are received by nearby RSU(s). These messages contain the timestamp, the vehicle’s current location, and other information that is used for other purposes. In the case when the detection and reporting are to be done on CSs, but not by the vehicle only, we have two cases.


### 4.2.1. When Vehicles Broadcast Their Real-Time Speed

If a vehicle is broadcasting its real-time speed, then RSUs will receive these messages. Each RSU will encapsulate the received messages and sends them to CSs. The encapsulated messages contain the RSU ID. Thus, CSs can know the rated speed limits for the area covered by that RSU. The CSs will have for each vehicle the vehicle speed and the allowed speed limits as a function of time (the timestamp of each V2I message). CSs compare the allowed speed limits with each vehicle to know if the vehicle is violating the speed limit or not. The challenge here is to obtain the duration of the over-/underspeeding and the maximum/minimum reached speeds. CSs can easily determine if a vehicle is violating or not. In the case of a violation, CSs can obtain all the details of the violation (start time, duration, peak speed, location, etc.) from the available data. This can be done by slightly modifying Algorithm1, as given in the previous section.


### 4.2.2. When Vehicles Broadcast Their Temporal Locations Only

The minimum information to be sent from a vehicle to RSU is the vehicle’s temporal location. If a vehicle is not broadcasting its real-time speed, then the vehicle’s temporal location is enough to calculate the speed as a function of time. Similar to what is described in Section4.2.1, an RSU receives messages broadcasted from vehicles and encapsulates the messages and resends them to CSs. CSs calculate the temporal speed for a vehicle from temporal locations of the vehicle, then continue the processing following the same way as described in Section 4.2.1.To calculate the temporal speed from the temporal location, the following approach is used.For a given vehicle, for two consecutive broadcast messagesmi−1, mi, the vehicle at time ti−1 where at location Ri−1, then at time ti, it moved to location Pi, where Pi and Ri−1 are represented by latitude α and the longitude β in degrees. The distance between the two locations dPi,Pi−1 can be obtained by Haversine’s formula [64]. It is used to obtain the shortest distance between two points over the Earth’s surface as follows:(1)dRi,Ri−1=ℛ∗c,where ℛ is the radius of the Earth (mean radius = 6,371 km), where c=2∗atan2a,1−a, where a = sin2 (π(αi − αi−1)/360) + cos (παi/180) ∗ cos (παi−1/180) ∗ sin2 (π (βi − βi−1)/360).We can obtain the temporal speed of the vehicle as follows:(2)vi=dRi,Ri−1ti−ti−1.The CS can determine the start, duration, maximum/minimum speed, and location of any speed-limit violation committed by any vehicle from the temporal speed information according to Algorithm1.


## 4.2.1. When Vehicles Broadcast Their Real-Time Speed

If a vehicle is broadcasting its real-time speed, then RSUs will receive these messages. Each RSU will encapsulate the received messages and sends them to CSs. The encapsulated messages contain the RSU ID. Thus, CSs can know the rated speed limits for the area covered by that RSU. The CSs will have for each vehicle the vehicle speed and the allowed speed limits as a function of time (the timestamp of each V2I message). CSs compare the allowed speed limits with each vehicle to know if the vehicle is violating the speed limit or not. The challenge here is to obtain the duration of the over-/underspeeding and the maximum/minimum reached speeds. CSs can easily determine if a vehicle is violating or not. In the case of a violation, CSs can obtain all the details of the violation (start time, duration, peak speed, location, etc.) from the available data. This can be done by slightly modifying Algorithm1, as given in the previous section.


## 4.2.2. When Vehicles Broadcast Their Temporal Locations Only

The minimum information to be sent from a vehicle to RSU is the vehicle’s temporal location. If a vehicle is not broadcasting its real-time speed, then the vehicle’s temporal location is enough to calculate the speed as a function of time. Similar to what is described in Section4.2.1, an RSU receives messages broadcasted from vehicles and encapsulates the messages and resends them to CSs. CSs calculate the temporal speed for a vehicle from temporal locations of the vehicle, then continue the processing following the same way as described in Section 4.2.1.To calculate the temporal speed from the temporal location, the following approach is used.For a given vehicle, for two consecutive broadcast messagesmi−1, mi, the vehicle at time ti−1 where at location Ri−1, then at time ti, it moved to location Pi, where Pi and Ri−1 are represented by latitude α and the longitude β in degrees. The distance between the two locations dPi,Pi−1 can be obtained by Haversine’s formula [64]. It is used to obtain the shortest distance between two points over the Earth’s surface as follows:(1)dRi,Ri−1=ℛ∗c,where ℛ is the radius of the Earth (mean radius = 6,371 km), where c=2∗atan2a,1−a, where a = sin2 (π(αi − αi−1)/360) + cos (παi/180) ∗ cos (παi−1/180) ∗ sin2 (π (βi − βi−1)/360).We can obtain the temporal speed of the vehicle as follows:(2)vi=dRi,Ri−1ti−ti−1.The CS can determine the start, duration, maximum/minimum speed, and location of any speed-limit violation committed by any vehicle from the temporal speed information according to Algorithm1.


## 5. Dynamic and Adaptive Speed-Limit Violation Fine Calculation Policy

All the existing methods of speed-limit fine calculation are based on a single value (usually the detected vehicle speed) using the camera systems or the speed radars. One very promising contribution of this work is that using our proposed systems, much more information about the violation can be obtained as our system knows the real-time speed of the vehicle as well as the allowed speed limits in addition to the current weather conditions. Thus, our proposed systems can allow the collection and/or the knowledge of the following parameters:(i)
Start time of the speed-limit violation.(ii)
End time of the speed-limit violation. Thus, the duration of the violation can be calculated.(iii)
The maximum reached overspeeding or the minimum underspeeding, as well as the average violating speed.(iv)
The lane number during the violation.(v)
The vehicle types.(vi)
The location of the violation. Effects of over-/underspeeding differ from lane to lane.(vii)
History of the speed-limit violations of each vehicle. Drivers who are committing frequent speed-limit violations can be identified. The systems can know the number of violations in the same trip, day, week, or month.(viii)
The time of the day: for example, speed limits can be adjusted differently according to specific hours.(ix)
The weather condition. IoV infrastructure is connected with weather measurement sensors (that measure the current weather condition). This allows the real-time adjustment of the allowed speeds according to current weather conditions. For example, if the maximum allowed speed in normal weather conditions (as reported by the speed-limit service provider) for a sedan vehicle is 120 km/h, then the allowed speed can be 100 km/h in rainy conditions, 70 km/h in snowy condition, and 40 km/h in foggy condition. The RSU broadcasts the real-time speed limits according to the weather condition, and thus, the proposed system detects and reports the violations accordingly. Almost all the existing systems cannot detect the violations in bad weather conditions (for example, camera systems cannot detect violations in foggy conditions). Our proposed systems are immune to weather conditions and can detect any violation using dynamic real-time speed limits.All this collected information about the violation can enable the traffic authorities to implement dynamic fine calculation policies for speed-limit violations. For example, the fine can be $10 if the duration of a violation is one minute, and it can be $300 if a violation lasts for 20 minutes. Furthermore, the fine can be $500 if the vehicle speed is 120 km/h and the weather condition is foggy. Another example, if the average overspeeding is 20 km/h, the fine can be $200, but it could be $700 if the average overspeeding during the violation is 80 km/h.One other feature of the system is that a driver can be warned (vocally and visually) by OBU if he/she is about to violate the allowed speed. This warning can significantly reduce the number of speed-limit violations.


## 6. Development of Working Prototype System

To validate the proposed systems, we have implemented them on a prototype system. We have implemented a simplified IoV testbed that consists of Raspberry Pi 4, GNSS receivers, Internet Connectivity, Speakers, LCDs, and other equipment, as shown in Figure7. We have developed the IoV essential working stack on Raspberry Pi 4, and we have set up the ad hoc network and both V2V and V2I communication. In addition, we have developed the Cloud Server essential services hosted and secured in a secure data center with 500 Mbps Internet dedicated connection and operated by VMWare vSphere. For the digital maps and the speed-limit service, we have used two subscriptions for two different service providers: MS Bing and HERE technologies. We have implemented Algorithm 1 (Section 4.1) and then tested and validated the prototype. We have conducted several tests on different road types: side roads, local roads, and highways. The prototype could effectively detect and report all the speed-limit violations committed by the vehicle to the CS. The applications of the CS were developed in Django. The reported speed-limit violation information can effectively be used by the traffic authorities to implement dynamic traffic fine calculation policies because of the different important information that is collected about the committed violations.Figure 7
Developed prototype in action.Several real-time validations of the system are conducted in different cities. The system is very accurate in detecting the speed-limit violation, under the condition that the speed-limit service provider (MS Bing in the prototype) is reporting correct values of the speed limits. In this case, the accuracy is 100%. In the production system to be deployed in the smart cities and the Intelligent Transportation Systems (ITSs), the authorities must be sure of the accuracy of the speed-limit service provider(s) to be used in the proposed systems.


## 7. Conclusions and Future Directions

In this paper, two different systems are proposed to automatically detect and report speed-limit violations using IoV technology without involving any extra hardware. The proposed systems extend the existing Internet of Vehicles (IoV) by only updating the firmware/software of the On-Board Unit (OBU) of the vehicle, the Road Side Unit (RSU), and the Cloud Servers (CSs). In the first proposed system, the OBU of the vehicle itself detects if the vehicle is violating the allowed speed limits and, in such a case, several useful information about the committed violation such as the start time, the duration of the same violation, the peak speed during the violation, the lane, and the road information. This enables modern dynamic and adaptive fine calculation policies that were not possible using the existing techniques. In addition, the violations will be detected and reported anywhere on the road anytime. This means that all the roads will be fully monitored, unlike the exiting techniques that are installed in a few fixed locations on the roads (thus monitoring only these few fixed areas). The proposed systems are very accurate and reliable. The deployment of such systems could effectively reduce/minimize road accidents and causalities. We have validated the proposed system by building a hardware prototype of IoV and developed the speed-limit violation detection and reporting system on top of that prototype. The developed prototype effectively and accurately detects any speed-limit violation on the road.Future research work may include developing a real system in practice for the IoV protocol stack. In addition, standardizing the speed-limit violation based on IoV is an essential perspective. Furthermore, automating the detection of other traffic violations such as tailgating is another important future work. Although this work relies on the security layer of IoV, which has been studied intensively in the literature and can be considered secure enough to avoid reporting bogus (tampered) location or speed information, it is important to consider the security aspects of such systems in the future work.



---

*Source: 9888789-2021-09-24.xml*