# Development and Testing of Road Signs Alert System Using a Smart Mobile Phone

Authors: Eric M. Masatu; Ramadhani Sinde; Anael Sam
Journal: Journal of Advanced Transportation
 (2022)

---

## Abstract

Road traffic accident is a major problem worldwide resulting in significant morbidity and mortality. Advanced driver assistance systems are one of the salient features of intelligent systems in transportation. They improve vehicle safety by providing real-time traffic information to the driver. Road signs play an important role in road safety. To be effective, road signs must be visible at a distance that enables drivers to take the necessary actions. However, static road signs are often seen too late for a driver to respond accordingly. In this study, a system for alerting drivers about road signs has been developed and tested using a smart mobile phone. The study was carried out in Tanzania along an 80 km highway stretch from Arusha to Moshi town. The Haversine formula was used to measure and estimate the distance between two pairs of coordinates using the smartphone-based navigation application, Google Map. The application provides a voice alert to a needed action that enhances driver’s attention. We propose an alternative method that identifies and modifies a specific class of energy inefficiencies. According to the experimental results, the proposed methodology has the benefits of high accuracy within a user radius of 10 meters, minimum bandwidth, and low-cost application. Furthermore, the system application was secured by limiting access to the application program interface key to avoid unauthorized access to sensitive information.


---

## Body

## 1. Introduction

Road traffic accidents (RTA) are defined as accidents that occurred or originated on a way or street open to public traffic. These collisions result in injury or death between automobiles or humans [1]. RTA is a major problem worldwide resulting in significant morbidity and mortality. According to the World Health Organization road safety report of 2018, the number of road traffic deaths increased to 1.35 million in 2016 [2]. According to the report, 93% of global road accidents occurred in low- and middle-income countries, which account for 60% of the world's vehicles. The number of deaths from RTA in Africa is the highest in the world, 26.6 per 100,000 people [2]. Kenya had an RTA rate of 60 per 100,000 people in 2009 [3]. According to a study in Ethiopia, the magnitude of road traffic accidents was 23.17% [4]. RTA is a public health issue in Tanzania. A study done on the Moshi-Arusha highway found considerable proportions of accidents at various blackspots such as the Kikavu River 60%, Kikatiti 20%, the Nduruma bridge 10%, the Kilala slope 5%, and Sadec 5% [5]. RTAs cause morbidity and mortality, as well as economic and emotional consequences. According to the data published by WHO in 2018, deaths from RTA in Tanzania reached 19,058 or 5.24% of total deaths. Tanzania ranked sixth in the world with an age-adjusted death rate of 46.17 per 100,000 population [6]. Costs for medical expenses, funerals, productivity loss, and property loss are among the economic, social, and emotional consequences [7, 8]. Driver factors such as dangerous driving and violation of traffic signs, as well as road factors such as poor road maintenance and lack of road signs, contribute to RTA [7]. Over speeding and lack of road signs have been identified as causes of road accidents in Tanzania [8–12]. Road maintenance, the use of road signs, the enforcement of traffic laws, speed control, and road safety education are some of the approaches being used to improve road safety in Tanzania [13].Road signs provide information to drivers to help them operate their vehicles safely. To be effective, road signs must be visible and legible at a sufficient distance to allow drivers to take appropriate actions. However, static road signs are frequently missed by drivers making it difficult for them to respond in time.Despite the presence of road signs on most Tanzanian highways, currently there is no information and communication technology (ICT)-based system in place to alert drivers in advance and real time about the location of those road signs. As a result, drivers encounter road signs at a short distance, making them unable to take the necessary precautions in time. This could lead them to apply the brakes abruptly, an action that may cause an accident. Advanced driver assistance systems (ADASs) improve road safety by informing drivers about upcoming road conditions such as curves, bumps, speed humps, pedestrian crossings, and speed limits. To be effective, the alerts must be given at the farthest possible distance so that the driver has enough time to decide timely.The purpose of this study was to develop a system that uses a smartphone to notify drivers about road signs ahead. The development of the smartphone application was motivated by the fact that smartphones are widely used nowadays. According to Samsung’s 2021 publication, an estimated 6.06 billion smartphones were in use worldwide at the end of 2020 [14]. According to the quarterly statistics report of the Tanzania Communications Regulations Authority (TCRA) for March 2021, the number of mobile phone users increased from 40.0 million in 2016 to 51.2 million in 2020 [15]. Smartphones include features such as a global positioning system (GPS), a database, microelectronic systems, and an inertial measurement unit (IMU). These smartphone features can be used to provide information about the location of road signs, the vehicle’s speed, and the time required to reach the road signs ahead. As a result, smartphones provide a golden opportunity for enhancing vehicle safety.


## 2. Related Works

A review of the literature on road safety revealed several approaches that are being used to avoid accidents. According to the review, the related approaches are divided into three themes: road sign colour and shape recognition, vehicle-to-roadside infrastructure communication, and vehicle-to-vehicle communication.


### 2.1. Theme 1: Road Signs Colour and Shape Recognition

Several studies on road safety have been conducted using a device onboard a vehicle to detect and recognize signs. García-Garrido et al. developed a traffic sign recognition system that uses a vision camera mounted on a vehicle. Based on the colours and shapes of the road signs, the system detected and recognized them [16]. The studies by Farhat et al. and Hechri et al. found a recognition of road signs with an average accuracy of about 95.53% and 92.8%, respectively [17, 18]. However, recognizing road signs based on colours and images presents numerous challenges. These include lighting conditions that vary naturally with the time of day and weather conditions; images that have been buffed by a moving vehicle's vibration; fading of paint on the sign; and occlusion of the sign by obstacles such as a tree, street lamp, or buildings.Another study by Ling and Seng used a mobile phone, the study used a smartphone back camera to recognize traffic signs and alert drivers for an incoming sign. The phone was placed on a windscreen for the camera to face the road. The distinct advantage of the system was that it did not require additional hardware. However, the main problem experienced was the low detection rate, light variation, and weather conditions [19].


### 2.2. Theme 2: Vehicle-to-Roadside Infrastructure Communication

Other approaches have used mobile devices on a vehicle and communication infrastructure on the road. The study by Rajale et al. developed a road sign notification system based on the global positioning system (GPS) and wireless radio frequency identification (RFID) technology [20]. A database of road signs and their locations was created. RFID transmitters were placed at the locations of road signs, and a receiver was placed in the vehicle. Using the system, drivers were alerted about the next road signs at some predetermined specific distance before the road signs were encountered. However, the use of RFID transmitters in two-way traffic could be limited, in the sense that their signals might be detected by vehicles traveling in the opposite direction. Thus, this situation can be misleading the drivers. Also, the devices are expensive and require a constant power supply and regular maintenance.Few studies have used wireless local area network (WLAN) mobile device technology to provide information about road signs. Katajasalo and Ikonen used wireless transmitters fitted on road signs to send traffic sign information to drivers through a WLAN mobile device within the vehicle [21]. However, when the transmitters were close to each other, the separation of relevant traffic sign information from the vehicle was problematic. Bhawiyuga et al. developed a communication system consisting of two devices; a road side unit (RSU) deployed on the road sign and an on-board unit (OBU) deployed in a vehicle [22]. Information about the road signs ahead was wirelessly communicated to drivers using two units. However, information transfer between modules was hindered by the speed of the vehicles in terms of delay and packet loss. Furthermore, the attenuation of wireless signals decreases as the transmitter-receiver increases distance.Another study by Toh et al. proposed the use of Wi-Fi connectivity for wireless digital traffic signs [23]. The study was capable of transmitting the traffic sign information wirelessly in the vehicle displays. The drivers were informed at an average distance between 70 and 98 meters. However, the device required a constant power supply. In addition, when a driver travelled at a speed greater than 60 km/h, the average distance was not enough to provide timely alerts.Other challenges of RSU reported by Faezipour et al. were prioritization and queuing due to the number of data processed from many nodes [24].


### 2.3. Theme 3: Vehicle-to-Vehicle Communication (V2V)

The approach of V2V communication is used to interchange reliable information between automobiles on a network. In this approach, the broadcast information can include a warning while traveling on a similar road. The V2V wireless technology works as an automated system to control and properly inform drivers by exchanging accurate information. However, the most challenging issues with this approach were the connectivity between V2V and vehicle infrastructure (V2I), mobility that allows vehicle area network (VAN) to change its topology quickly, and violation of driver privacy and security [24, 25]. Another challenge is the variation in the broadcast information offered by different types of vehicle manufacturers [26, 27].


## 2.1. Theme 1: Road Signs Colour and Shape Recognition

Several studies on road safety have been conducted using a device onboard a vehicle to detect and recognize signs. García-Garrido et al. developed a traffic sign recognition system that uses a vision camera mounted on a vehicle. Based on the colours and shapes of the road signs, the system detected and recognized them [16]. The studies by Farhat et al. and Hechri et al. found a recognition of road signs with an average accuracy of about 95.53% and 92.8%, respectively [17, 18]. However, recognizing road signs based on colours and images presents numerous challenges. These include lighting conditions that vary naturally with the time of day and weather conditions; images that have been buffed by a moving vehicle's vibration; fading of paint on the sign; and occlusion of the sign by obstacles such as a tree, street lamp, or buildings.Another study by Ling and Seng used a mobile phone, the study used a smartphone back camera to recognize traffic signs and alert drivers for an incoming sign. The phone was placed on a windscreen for the camera to face the road. The distinct advantage of the system was that it did not require additional hardware. However, the main problem experienced was the low detection rate, light variation, and weather conditions [19].


## 2.2. Theme 2: Vehicle-to-Roadside Infrastructure Communication

Other approaches have used mobile devices on a vehicle and communication infrastructure on the road. The study by Rajale et al. developed a road sign notification system based on the global positioning system (GPS) and wireless radio frequency identification (RFID) technology [20]. A database of road signs and their locations was created. RFID transmitters were placed at the locations of road signs, and a receiver was placed in the vehicle. Using the system, drivers were alerted about the next road signs at some predetermined specific distance before the road signs were encountered. However, the use of RFID transmitters in two-way traffic could be limited, in the sense that their signals might be detected by vehicles traveling in the opposite direction. Thus, this situation can be misleading the drivers. Also, the devices are expensive and require a constant power supply and regular maintenance.Few studies have used wireless local area network (WLAN) mobile device technology to provide information about road signs. Katajasalo and Ikonen used wireless transmitters fitted on road signs to send traffic sign information to drivers through a WLAN mobile device within the vehicle [21]. However, when the transmitters were close to each other, the separation of relevant traffic sign information from the vehicle was problematic. Bhawiyuga et al. developed a communication system consisting of two devices; a road side unit (RSU) deployed on the road sign and an on-board unit (OBU) deployed in a vehicle [22]. Information about the road signs ahead was wirelessly communicated to drivers using two units. However, information transfer between modules was hindered by the speed of the vehicles in terms of delay and packet loss. Furthermore, the attenuation of wireless signals decreases as the transmitter-receiver increases distance.Another study by Toh et al. proposed the use of Wi-Fi connectivity for wireless digital traffic signs [23]. The study was capable of transmitting the traffic sign information wirelessly in the vehicle displays. The drivers were informed at an average distance between 70 and 98 meters. However, the device required a constant power supply. In addition, when a driver travelled at a speed greater than 60 km/h, the average distance was not enough to provide timely alerts.Other challenges of RSU reported by Faezipour et al. were prioritization and queuing due to the number of data processed from many nodes [24].


## 2.3. Theme 3: Vehicle-to-Vehicle Communication (V2V)

The approach of V2V communication is used to interchange reliable information between automobiles on a network. In this approach, the broadcast information can include a warning while traveling on a similar road. The V2V wireless technology works as an automated system to control and properly inform drivers by exchanging accurate information. However, the most challenging issues with this approach were the connectivity between V2V and vehicle infrastructure (V2I), mobility that allows vehicle area network (VAN) to change its topology quickly, and violation of driver privacy and security [24, 25]. Another challenge is the variation in the broadcast information offered by different types of vehicle manufacturers [26, 27].


## 3. Materials and Methods

### 3.1. Research Framework

Several steps were undertaken in this study, as shown in Figure1. The first step was to review the literature of the relevant related studies to gain insights about road signs identification. The purpose of this step was to identify information that will guide the design of this proposed work. The second step was to collect data from stakeholders in Tanzania who matter as far as road safety is concerned. The purpose was to get stakeholders’ inputs on the proposed work, regarding functional and nonfunctional requirements. The third step was system development that began with mapping the road signs of interest to create a database of coordinates that corresponded to the alerts. This was followed by system design comprising of system architecture design, use case diagram, data flow diagram, and database design. Furthermore, the existing related system was taken into account during the design phase. Finally, the mobile application was pretested in the study area. The results were analysed during the final step to evaluate the system performance.Figure 1
A research framework.


### 3.2. Road Mapping

Software was created and used to accurately map road signs, coordinates, and distances. By modifying the location class used in this study, the recorder application was obtained. The application was created using the study’s public class location manager. This class provides access to the system location service and enables the smartphone application to receive periodic device updates. Using the location change method, this class was configured to return coordinates in the 0–10-meter range with an accuracy of less than 5 meters. After setting and calculating, the mobile application saves the coordinates. These settings enabled the researchers to carefully record the coordinates of the road signs. The coordinates of road signs of interest were recorded from Moshi to Arusha highway. These data were then stored in the proposed javascript object notation (JSON) database.


### 3.3. System Development

Our system includes a GPS sensor built into the smartphone, an accelerometer, a gyro sensor, and an inertia measure unit (IMU). The system is built with the Android Studio integrated development environment (IDE), JSON data format, Google Cloud Console, Google Map application program interface (API), and software development kit (SDK) Map for Android. The geometric position of the road signs was collected using a study-generated recorder application and stored in the application database. To display a map with road signs, the system makes use of Google Maps APIs. Furthermore, the proposed work includes a screen on which the drivers can view their current speed, as well as an option button for speed limit notification. The Haversine formula is used to calculate the length of a great circle between two points on the Earth’s sphere. The alert is generated by determining the coordinate that is closest to the predetermined road sign. The alert was set to be released by the function when a distance is within a close range of 250 meters. When the system has verified the accuracy of navigation location, the distance is calculated after every 3–5 meters, with the fastest interval of 1–10 nanoseconds and a location priority request set to be high. The function returns geolocations with an accuracy of less than 10 meters. To improve real-time performance, the system can also provide critical information if the network drops to the edge network. The use of an offline database helps reduce bandwidth usage and correct resolution of the network coverage problem. This database will not require network connectivity (mobile data) to function properly. Rather, it stores information about road signs locally. Finally, the framework application package (APK) was generated by Android Studio and installed on the drivers' smartphones.


#### 3.3.1. System Development Approach

During the development of an application, the rapid application development (RAD) model was used. The model is a software development methodology based on agile principles. During the requirements stage, the data collected from the key stakeholders were used to determine the initial user preferences. Before interacting with the mobile application, volunteers were shown a demonstration on how the prototype works. Finally, all discovered bugs were worked out iteratively. The driver tested the mobile application, and then a meeting with them was held to discuss what worked and what did not work before the final product was released.


#### 3.3.2. Proposed Distance

The data in Figure2 show the mathematical relationship between the driver’s average linear speed and the time taken to reach a road sign when an alert is received. When alerts are issued, the spotted distance is within a range of 250 meters. This is a reasonable warning distance for drivers to respond to alerts. The audio notification can last up to 0.05 seconds. For example, when the driver is driving at an average linear speed of 60 km/h and is 250 meters away from a road sign, the driver will take 15 seconds to come across the road sign. The application audio alert with a maximum duration of 0.05 seconds will be issued within 15 seconds before the sign.Figure 2
Average vehicle linear speed vs time taken when the alert is first received.The formula for average linear speed is as follows:(1)linear speed≡ΔDistanceΔTime taken.The above formula is for the average linear speed formula. It is the measure of the change in linear speed with respect to time over a given period. ∆Distance represents the change in distance and ∆Time represents the time taken by the vehicle to traverse the given distance.


#### 3.3.3. Distance Determination

The Haversine formula is used to calculate the length of a great circle between two points on the Earth’s sphere. The formula gives approximate results about the real distances [28]. It calculates the distance from the road sign coordinates stored in a JSON array based on the driver’s geographical navigation position as equations (2)–(4). The alert is generated by determining the point that is closest to the predetermined road sign. The closest distance was set to be in a close range of 250 meters to reach the point.Haversine general equations are as follows:(2)a=sin2Δ∅2+cos∅1∗cos∅2∗sin2Δλ2,(3)c=2∗asina,(4)d=R∗c.The equations given above are for the Haversine formula.∅ represents latitude, λ represents longitude, R is the radius of the Earth (mean radius = 6371 km), a represents the square of half chord length between the points, c represents the angular distance between two points (in radians), and d is the distance in meters.(5)Δ∅=lat2−lat1∗π180Δλ=long2−long∗π180.Note that the angles need to be in radians.


### 3.4. System Design

#### 3.4.1. Architectural Design

Figure3 depicts the proposed system architecture design. The system is made up of a mobile application, a database server, a satellite, and road signs. The JSON determines the distances between road signs using satellite and GPS data. The Haversine formula will calculate the distance required to reach the sign. When the calculated distance is found to be within the proposed range, a voice alert will be sent to the vehicle driver to take the necessary action on time.Figure 3
Architectural design.


#### 3.4.2. Use Case Diagram

The use case diagram shown in Figure4 is used to describe how a user interacts with the system. The system has two types of users: system administrators and drivers, as described in Tables 1 and 2, respectively.Figure 4
Use case diagram.Table 1
Description of administrator use cases.
Use caseDescriptionActorView application sensor logsThe administrator can view the GPS sensor logs such as distance, accuracy, and alert releasedAdminCloud reportThe administrator can view cloud metric reports such as the number of requests, traffic usage, errors reported, and latencyAdminView the number of requestsThe administrator can view the number of API requests made by usersAdminView traffic usageThe administrator can view the daily, monthly traffic usage by usersAdminView error by the responseThe administrator can view errors reported by application service responseAdminView median latencyThe administrator can be able to view if the application is experiencing high latencyAdminTable 2
Description of driver use cases.
Use caseDescriptionActorChoose destinationThe user can select the destination route, that is, it is from Arusha to Moshi or Moshi to Arusha routeDriverEnable locationThe user can allow access to the location serviceDriverView roadmapThe user can view a road mapDriverView road signsThe user can view locations where road signs were spottedDriverView current locationThe user can view the current location as well as navigation when moving from one position to anotherDriverView current speedThe user can view the current speed when accelerating or decelerating from one position to anotherDriverReceive alert notificationThe user can receive both image and voice alert notifications when the vehicle is approaching the road signsDriverSet speed limits notificationThe user can set a speed limit notificationDriver


#### 3.4.3. Data Flow Diagram

Figure5 shows how the proposed work is issuing an alert. Road sign information is contained in a JSON file string. When the application is started from the main activity, a background tracking activity continuously communicates with GPS satellites and provides the vehicle’s current location in decimal degrees. Following the start of the background service, the tracking activity begins, and the accuracy of the coordinates broadcasted is evaluated. This technique improves the accuracy of location estimates and distance calculations during navigation. When the coordinates are released, the first condition is to verify if the accuracy is less than 10 meters. We consider any accuracy that exceeds that limit to be erroneous. If these conditions are met, the function uses the Haversine formula to calculate distance. Using a for loop, the Haversine formula will calculate the distance in meters between the current vehicle position and an upcoming road sign stored in the JSON file. When the distance to the road sign is determined to be within a close range of 250 meters, the driver will receive a voice alert.Figure 5
Back-end data flow.


#### 3.4.4. Database Design

The JSON data structure was used during the system's development. It presents data in array and object formats that are readable by humans. The JSON array consists of nine column lists of longitude, latitude, signal, alerts, audio, direction, position, visibility, and alpha. The longitude and latitude contain the road sign coordinates. The signal, alert, and audio columns store the relevant alert notifications. The direction, position, visibility, and alpha store the destination route, road sign names, and visibility. By using a for loop, these values are instantly accessed, and notifications are delivered to the driver.


## 3.1. Research Framework

Several steps were undertaken in this study, as shown in Figure1. The first step was to review the literature of the relevant related studies to gain insights about road signs identification. The purpose of this step was to identify information that will guide the design of this proposed work. The second step was to collect data from stakeholders in Tanzania who matter as far as road safety is concerned. The purpose was to get stakeholders’ inputs on the proposed work, regarding functional and nonfunctional requirements. The third step was system development that began with mapping the road signs of interest to create a database of coordinates that corresponded to the alerts. This was followed by system design comprising of system architecture design, use case diagram, data flow diagram, and database design. Furthermore, the existing related system was taken into account during the design phase. Finally, the mobile application was pretested in the study area. The results were analysed during the final step to evaluate the system performance.Figure 1
A research framework.


## 3.2. Road Mapping

Software was created and used to accurately map road signs, coordinates, and distances. By modifying the location class used in this study, the recorder application was obtained. The application was created using the study’s public class location manager. This class provides access to the system location service and enables the smartphone application to receive periodic device updates. Using the location change method, this class was configured to return coordinates in the 0–10-meter range with an accuracy of less than 5 meters. After setting and calculating, the mobile application saves the coordinates. These settings enabled the researchers to carefully record the coordinates of the road signs. The coordinates of road signs of interest were recorded from Moshi to Arusha highway. These data were then stored in the proposed javascript object notation (JSON) database.


## 3.3. System Development

Our system includes a GPS sensor built into the smartphone, an accelerometer, a gyro sensor, and an inertia measure unit (IMU). The system is built with the Android Studio integrated development environment (IDE), JSON data format, Google Cloud Console, Google Map application program interface (API), and software development kit (SDK) Map for Android. The geometric position of the road signs was collected using a study-generated recorder application and stored in the application database. To display a map with road signs, the system makes use of Google Maps APIs. Furthermore, the proposed work includes a screen on which the drivers can view their current speed, as well as an option button for speed limit notification. The Haversine formula is used to calculate the length of a great circle between two points on the Earth’s sphere. The alert is generated by determining the coordinate that is closest to the predetermined road sign. The alert was set to be released by the function when a distance is within a close range of 250 meters. When the system has verified the accuracy of navigation location, the distance is calculated after every 3–5 meters, with the fastest interval of 1–10 nanoseconds and a location priority request set to be high. The function returns geolocations with an accuracy of less than 10 meters. To improve real-time performance, the system can also provide critical information if the network drops to the edge network. The use of an offline database helps reduce bandwidth usage and correct resolution of the network coverage problem. This database will not require network connectivity (mobile data) to function properly. Rather, it stores information about road signs locally. Finally, the framework application package (APK) was generated by Android Studio and installed on the drivers' smartphones.


### 3.3.1. System Development Approach

During the development of an application, the rapid application development (RAD) model was used. The model is a software development methodology based on agile principles. During the requirements stage, the data collected from the key stakeholders were used to determine the initial user preferences. Before interacting with the mobile application, volunteers were shown a demonstration on how the prototype works. Finally, all discovered bugs were worked out iteratively. The driver tested the mobile application, and then a meeting with them was held to discuss what worked and what did not work before the final product was released.


### 3.3.2. Proposed Distance

The data in Figure2 show the mathematical relationship between the driver’s average linear speed and the time taken to reach a road sign when an alert is received. When alerts are issued, the spotted distance is within a range of 250 meters. This is a reasonable warning distance for drivers to respond to alerts. The audio notification can last up to 0.05 seconds. For example, when the driver is driving at an average linear speed of 60 km/h and is 250 meters away from a road sign, the driver will take 15 seconds to come across the road sign. The application audio alert with a maximum duration of 0.05 seconds will be issued within 15 seconds before the sign.Figure 2
Average vehicle linear speed vs time taken when the alert is first received.The formula for average linear speed is as follows:(1)linear speed≡ΔDistanceΔTime taken.The above formula is for the average linear speed formula. It is the measure of the change in linear speed with respect to time over a given period. ∆Distance represents the change in distance and ∆Time represents the time taken by the vehicle to traverse the given distance.


### 3.3.3. Distance Determination

The Haversine formula is used to calculate the length of a great circle between two points on the Earth’s sphere. The formula gives approximate results about the real distances [28]. It calculates the distance from the road sign coordinates stored in a JSON array based on the driver’s geographical navigation position as equations (2)–(4). The alert is generated by determining the point that is closest to the predetermined road sign. The closest distance was set to be in a close range of 250 meters to reach the point.Haversine general equations are as follows:(2)a=sin2Δ∅2+cos∅1∗cos∅2∗sin2Δλ2,(3)c=2∗asina,(4)d=R∗c.The equations given above are for the Haversine formula.∅ represents latitude, λ represents longitude, R is the radius of the Earth (mean radius = 6371 km), a represents the square of half chord length between the points, c represents the angular distance between two points (in radians), and d is the distance in meters.(5)Δ∅=lat2−lat1∗π180Δλ=long2−long∗π180.Note that the angles need to be in radians.


## 3.3.1. System Development Approach

During the development of an application, the rapid application development (RAD) model was used. The model is a software development methodology based on agile principles. During the requirements stage, the data collected from the key stakeholders were used to determine the initial user preferences. Before interacting with the mobile application, volunteers were shown a demonstration on how the prototype works. Finally, all discovered bugs were worked out iteratively. The driver tested the mobile application, and then a meeting with them was held to discuss what worked and what did not work before the final product was released.


## 3.3.2. Proposed Distance

The data in Figure2 show the mathematical relationship between the driver’s average linear speed and the time taken to reach a road sign when an alert is received. When alerts are issued, the spotted distance is within a range of 250 meters. This is a reasonable warning distance for drivers to respond to alerts. The audio notification can last up to 0.05 seconds. For example, when the driver is driving at an average linear speed of 60 km/h and is 250 meters away from a road sign, the driver will take 15 seconds to come across the road sign. The application audio alert with a maximum duration of 0.05 seconds will be issued within 15 seconds before the sign.Figure 2
Average vehicle linear speed vs time taken when the alert is first received.The formula for average linear speed is as follows:(1)linear speed≡ΔDistanceΔTime taken.The above formula is for the average linear speed formula. It is the measure of the change in linear speed with respect to time over a given period. ∆Distance represents the change in distance and ∆Time represents the time taken by the vehicle to traverse the given distance.


## 3.3.3. Distance Determination

The Haversine formula is used to calculate the length of a great circle between two points on the Earth’s sphere. The formula gives approximate results about the real distances [28]. It calculates the distance from the road sign coordinates stored in a JSON array based on the driver’s geographical navigation position as equations (2)–(4). The alert is generated by determining the point that is closest to the predetermined road sign. The closest distance was set to be in a close range of 250 meters to reach the point.Haversine general equations are as follows:(2)a=sin2Δ∅2+cos∅1∗cos∅2∗sin2Δλ2,(3)c=2∗asina,(4)d=R∗c.The equations given above are for the Haversine formula.∅ represents latitude, λ represents longitude, R is the radius of the Earth (mean radius = 6371 km), a represents the square of half chord length between the points, c represents the angular distance between two points (in radians), and d is the distance in meters.(5)Δ∅=lat2−lat1∗π180Δλ=long2−long∗π180.Note that the angles need to be in radians.


## 3.4. System Design

### 3.4.1. Architectural Design

Figure3 depicts the proposed system architecture design. The system is made up of a mobile application, a database server, a satellite, and road signs. The JSON determines the distances between road signs using satellite and GPS data. The Haversine formula will calculate the distance required to reach the sign. When the calculated distance is found to be within the proposed range, a voice alert will be sent to the vehicle driver to take the necessary action on time.Figure 3
Architectural design.


### 3.4.2. Use Case Diagram

The use case diagram shown in Figure4 is used to describe how a user interacts with the system. The system has two types of users: system administrators and drivers, as described in Tables 1 and 2, respectively.Figure 4
Use case diagram.Table 1
Description of administrator use cases.
Use caseDescriptionActorView application sensor logsThe administrator can view the GPS sensor logs such as distance, accuracy, and alert releasedAdminCloud reportThe administrator can view cloud metric reports such as the number of requests, traffic usage, errors reported, and latencyAdminView the number of requestsThe administrator can view the number of API requests made by usersAdminView traffic usageThe administrator can view the daily, monthly traffic usage by usersAdminView error by the responseThe administrator can view errors reported by application service responseAdminView median latencyThe administrator can be able to view if the application is experiencing high latencyAdminTable 2
Description of driver use cases.
Use caseDescriptionActorChoose destinationThe user can select the destination route, that is, it is from Arusha to Moshi or Moshi to Arusha routeDriverEnable locationThe user can allow access to the location serviceDriverView roadmapThe user can view a road mapDriverView road signsThe user can view locations where road signs were spottedDriverView current locationThe user can view the current location as well as navigation when moving from one position to anotherDriverView current speedThe user can view the current speed when accelerating or decelerating from one position to anotherDriverReceive alert notificationThe user can receive both image and voice alert notifications when the vehicle is approaching the road signsDriverSet speed limits notificationThe user can set a speed limit notificationDriver


### 3.4.3. Data Flow Diagram

Figure5 shows how the proposed work is issuing an alert. Road sign information is contained in a JSON file string. When the application is started from the main activity, a background tracking activity continuously communicates with GPS satellites and provides the vehicle’s current location in decimal degrees. Following the start of the background service, the tracking activity begins, and the accuracy of the coordinates broadcasted is evaluated. This technique improves the accuracy of location estimates and distance calculations during navigation. When the coordinates are released, the first condition is to verify if the accuracy is less than 10 meters. We consider any accuracy that exceeds that limit to be erroneous. If these conditions are met, the function uses the Haversine formula to calculate distance. Using a for loop, the Haversine formula will calculate the distance in meters between the current vehicle position and an upcoming road sign stored in the JSON file. When the distance to the road sign is determined to be within a close range of 250 meters, the driver will receive a voice alert.Figure 5
Back-end data flow.


### 3.4.4. Database Design

The JSON data structure was used during the system's development. It presents data in array and object formats that are readable by humans. The JSON array consists of nine column lists of longitude, latitude, signal, alerts, audio, direction, position, visibility, and alpha. The longitude and latitude contain the road sign coordinates. The signal, alert, and audio columns store the relevant alert notifications. The direction, position, visibility, and alpha store the destination route, road sign names, and visibility. By using a for loop, these values are instantly accessed, and notifications are delivered to the driver.


## 3.4.1. Architectural Design

Figure3 depicts the proposed system architecture design. The system is made up of a mobile application, a database server, a satellite, and road signs. The JSON determines the distances between road signs using satellite and GPS data. The Haversine formula will calculate the distance required to reach the sign. When the calculated distance is found to be within the proposed range, a voice alert will be sent to the vehicle driver to take the necessary action on time.Figure 3
Architectural design.


## 3.4.2. Use Case Diagram

The use case diagram shown in Figure4 is used to describe how a user interacts with the system. The system has two types of users: system administrators and drivers, as described in Tables 1 and 2, respectively.Figure 4
Use case diagram.Table 1
Description of administrator use cases.
Use caseDescriptionActorView application sensor logsThe administrator can view the GPS sensor logs such as distance, accuracy, and alert releasedAdminCloud reportThe administrator can view cloud metric reports such as the number of requests, traffic usage, errors reported, and latencyAdminView the number of requestsThe administrator can view the number of API requests made by usersAdminView traffic usageThe administrator can view the daily, monthly traffic usage by usersAdminView error by the responseThe administrator can view errors reported by application service responseAdminView median latencyThe administrator can be able to view if the application is experiencing high latencyAdminTable 2
Description of driver use cases.
Use caseDescriptionActorChoose destinationThe user can select the destination route, that is, it is from Arusha to Moshi or Moshi to Arusha routeDriverEnable locationThe user can allow access to the location serviceDriverView roadmapThe user can view a road mapDriverView road signsThe user can view locations where road signs were spottedDriverView current locationThe user can view the current location as well as navigation when moving from one position to anotherDriverView current speedThe user can view the current speed when accelerating or decelerating from one position to anotherDriverReceive alert notificationThe user can receive both image and voice alert notifications when the vehicle is approaching the road signsDriverSet speed limits notificationThe user can set a speed limit notificationDriver


## 3.4.3. Data Flow Diagram

Figure5 shows how the proposed work is issuing an alert. Road sign information is contained in a JSON file string. When the application is started from the main activity, a background tracking activity continuously communicates with GPS satellites and provides the vehicle’s current location in decimal degrees. Following the start of the background service, the tracking activity begins, and the accuracy of the coordinates broadcasted is evaluated. This technique improves the accuracy of location estimates and distance calculations during navigation. When the coordinates are released, the first condition is to verify if the accuracy is less than 10 meters. We consider any accuracy that exceeds that limit to be erroneous. If these conditions are met, the function uses the Haversine formula to calculate distance. Using a for loop, the Haversine formula will calculate the distance in meters between the current vehicle position and an upcoming road sign stored in the JSON file. When the distance to the road sign is determined to be within a close range of 250 meters, the driver will receive a voice alert.Figure 5
Back-end data flow.


## 3.4.4. Database Design

The JSON data structure was used during the system's development. It presents data in array and object formats that are readable by humans. The JSON array consists of nine column lists of longitude, latitude, signal, alerts, audio, direction, position, visibility, and alpha. The longitude and latitude contain the road sign coordinates. The signal, alert, and audio columns store the relevant alert notifications. The direction, position, visibility, and alpha store the destination route, road sign names, and visibility. By using a for loop, these values are instantly accessed, and notifications are delivered to the driver.


## 4. Results and Discussion

### 4.1. Results

#### 4.1.1. Requirements Identification

The first goal of this research was to identify the user and system requirements that could be incorporated into the system. This section presents the findings. The requirements have been classified into two groups: functional and nonfunctional requirements. The details are shown in Tables3–5.(i)
Functional requirementsThe behaviour of the system is defined by functional requirements. This is what the system should do if it is working properly. According to the findings, the developed mobile application should meet the functional requirements outlined in Tables3 and 4.(ii)
The nonfunctional requirementsThe nonfunctional requirements define what the system should be able to do. According to the findings, the developed mobile application should meet the nonfunctional requirements listed in Table5.Table 3
Functional requirements for drivers.
Requirement categoryRequirement descriptionSystem actorSet speed limit notificationThe user should set a speed limit notificationDriverMap visibilityThe system should allow the user to view the mapDriverRoad signsThe system should allow the user to see the road signsDriverReceive alertsThe system should provide notifications timelyDriverSpeed meterThe system should show the speed of the vehicleDriverTable 4
Functional requirements for the system administrator.
Requirement categoryRequirement descriptionSystem actorLogsThe system should show the sensor logsAdministratorView number of requestsThe system should view the number of APIs requests made by usersAdministratorView traffic usageThe system should view daily, weekly, and monthly application traffic usage in web UIAdministratorView error by the responseThe system should view the error reported by the application service response in the web UIAdministratorTable 5
Nonfunctional requirements.
Requirement categoryRequirement descriptionSecurityThe system should authenticate usersResponse timeThe system should respond quickly to user's requestReliabilityThe system should perform the intended tasks for a specific timeUsabilityThe system should be easy to install and simple to useScalabilityThe system should be able to add new featuresRobustnessThe system should function under different circumstances of disturbanceOperating systemThe system should be platform-independent, i.e., android OSPortabilityThe system should operate on android smart devices such as Android car kit TV, android smartphones, android tabletsAvailabilityThe system should be available all the time when requiredPerformanceThe system should perform well under different conditions


#### 4.1.2. Implementation Results

(1) System Implementation Results. As shown in Figure 6, the system was designed to run on an Android smartphone, an Android car multimedia player, and an Android tablet. The system has an appealing user interface for both devices, and it responds well to changes in screen size and orientation. A successful installation of the developed application is as simple as opening the APK and following the basic installation steps. Finally, when only an application is used, the user must grant access to storage and location.Figure 6
(a) Destination. (b) Enable access. (c) Speed notification. (d) Map screen. (e) Speed screen. (f) Image alert. (g) Sensor log.
(a)(b)(c)(d)(e)(f)(g)Upon using the developed application, the user must open an application icon. The application will launch, and a route selection prompt will appear as shown in Figure6(a), allowing users to select their intended destination. To enable location tracking, the user must enable location access by turning it on. The home screen contains a button for starting GPS. With this privileged access, GPS will be able to provide real-time coordinates to the mobile device, as shown in Figure 6(b). As shown in Figure 6(c), a set speed notification option button is also found on the home screen. To set a speed limit notification, the user must enable this option. The alarm signals an ascending tone when a speed limit is exceeded. As shown in Figure 6(d), a map screen is used to display a map to the mobile application. This interface displays a map showing the location of road signs. Depending on the route chosen, these visible signs are represented by a small blue and green circle. The blue circles will only appear if the user selects the intended Arusha to Moshi destination, whereas the green circles will only appear if the user selects the intended Moshi to Arusha destination.The signs were integrated with the Google Maps API. This map also shows the user's movement from one location to another. The speed screen displays the current speed of the driver. As shown in Figure6(e), this speedometer has three different colour signals: green, yellow, and red. The green colour represents a safe speed. All speeds less than 80 km/h will be displayed in this colour. This colour indicates that the driver is traveling at the speed recommended by the government for public vehicles. The yellow colour is a warning signal and indicates all speeds greater than 80 km/h but less than 120 km/h. This colour implies that the driver is driving at a high speed. The driver should slow down. The red colour is a danger signal, implying that a driver is traveling at a speed of more than 120 km/h. The driver should slow down.Alerts about road signs are provided by voice messages and road sign images. When drivers are within a close range of 250 meters before the road signs, valuable information is immediately conveyed to them. The voice is provided by a female voice agent. The female voice was more familiar to the participants because it was widely used in smartphones navigation systems. In addition, in a noisy environment, the female voice is easier to hear than the male voice. The image of the road sign will be displayed, as shown in Figure6(f).Figure6(g) shows the sensor logs written when an alert is immediately released. The log file contains important information such as the distance over which alerts were issued, specific coordinates when alerts were issued, and the accuracy of the coordinates released. The file also contains a specific type of alert released, date, and time as tangible proof that the appropriate notification was released.(2) Results of Web Application (Google Cloud Platform) Implementation. To timely monitor user traffic on an application, a Google cloud platform web application tool was integrated with our mobile application. The platform offers an important tool and API service for managing applications. The system cloud dashboard provides a convenient summary of cloud reports from mobile users to the system administrator. The dashboard provides a high-level view of the state of the mobile application, including the number of requests made, traffic responses, and latency. Additionally, errors reported by the cloud are also indicated. Furthermore, the security of access to information has been restricted to prevent unauthorized data sharing. By doing so, the mobile application was secured by limiting access to the API key. The method includes the application package as well as the Secure Hash Algorithm (SHA-1) signing certificate fingerprint.


#### 4.1.3. Resource Utilization Results

An Android profiler is a useful tool in Android Studio that provides real-time application information such as CPU usage, efficient memory allocation, active network, and battery. A Nokia 7.2 was used in this experiment to determine the resources used by a mobile application. This valuable information is used to optimize the performance of the potential application by identifying outstanding performance-related issues.The developed system was installed on a smartphone (Nokia 7.2, Android 10 API Level 29, Octa-core (4 × 2.2 GHz), 6 GB RAM, Li-Po 3500 mAh nonremovable battery, IPS LCD 6.3 inches). While driving a vehicle along a predetermined route, the smartphone was connected to a PC that visually tracked the resources. The raw data of resource utilization were being monitored in real-time. We evaluated our mobile application based on two activities: background and foreground. The goal was to visualize the instant energy consumption of the potential application when running on a smartphone. When the system was running, areas in which the application makes inefficient use of resources were identified. We reveal what happens during the successful execution of the application in the foreground and background. In both cases, we display the graphs of energy utilization when using the developed application.(i)
Foreground Activities ResultsFigure7 shows the results of the foreground activities measurements on the Android device. The results show a significant percentage of CPU, Memory, and Energy usage as follows.(a)
CPU usageThe CPU usage profile has the distinct advantage of displaying how specific functions consume CPU percentage time. The process helps to properly understand how the mobile application is executed and how valuable resources are allocated correctly. CPU usage was measured using an Android profiler tool, as shown in Figure7. The results show that the application CPU usage contributes to 12% of the total system CPU usage when the system is running.(b)
Memory usageA memory profile in the Android profiler is used to correctly identify the memory usage of applications. The critical component displays a real-time utilization of the running application, which aids in the detection of application memory leaks, freezing, and crashing. The memory utilization was measured as shown in Figure7. It was found that the application uses a total of 261 MB of memory, and graphics contributes a significant chunk of that usage.(c)
Energy usageThe energy profile in Android Profiler is used to correctly identify the energy usage of applications. It employs a model that estimates the amount of energy consumed by each resource. The CPU, network, radio, and GPS sensors are all monitored by the tool. Also, it provides a variety of points of interest, such as searching for issues related to unnecessary energy usage. We examined our application’s energy utilization activities, which cause battery drain and excess power consumption to stay awake. The usage was measured as shown in Figure7. It was found that the application contributes a light amount of energy usage. However, system events such as frequent location requests and speed determination contributed to significant energy consumption. The GPS sensor consumes a significant amount of energy while listening to and updating a location request. Furthermore, energy consumption becomes high as the sensor calculates speed when a vehicle navigates from one point to another.(ii)
Background Activities ResultsFigure8 shows the results of the background activities measurements on the Android device. The mobile application was minimized and allowed to run in the background to evaluate the activities. The results show that the CPU usage drops to 1%. The energy profile shows a low energy usage. Furthermore, the application memory usage was reduced to 227 MB of memory, the system killed some processes that consumed a significant amount of RAM, and the main activity was immediately terminated. During the application execution, the most recent data about the navigation screen could not be refreshed in some rare cases, and the application was required to restart.Figure 7
Foreground activities resources utilization.Figure 8
Background activities resource utilization.Based on the results of the experiments, we can conclude that running a mobile application in the background consumes less energy for each resource on a mobile device. However, the application cannot provide better performance in terms of providing drivers with the latest navigation updates and road sign notifications.(1) Evaluation. The performance output of a mobile application on mobile devices varies depending on its practical use. In this experiment, the evaluation was carried out when the mobile application was running in the foreground and background. This experiment was carried out solely to demonstrate the importance of these fundamental concepts.Based on the results of the experiments, we can conclude that running the application in the foreground results in better performance in providing appropriate notifications to the mobile application users. The mobile application runs at high frequency, and the appropriate notifications are gradually released over a long period of time at a safe distance within 250 meters. Most of the time, the GPS sensor uses a significant amount of energy while listening to and updating a location request. This system may have a limitation that affects resources such as energy, memory, and CPU on any mobile device’s power consumption. When a mobile application is minimized, it produces better resource performance indicators than when it is in the foreground. However, in some cases, the most recent data about the navigation screen could not be refreshed, necessitating a restart.


### 4.2. Discussion

This study developed an Android mobile application for drivers as a tool to help them determine the upcoming road signs at an appropriate distance. The system's potential benefit is enhancing vehicle safety by providing real-time traffic information to the user.The study found that at 250 meters before reaching a road sign, drivers have enough time to act appropriately. Despite the presence of road signs on most Tanzanian highways, the placement of these signs requires careful thought and planning. Road signs must be carefully placed at the farthest distance ahead of the intended warning. Static road signs are frequently seen too late at a certain close range of 10–50 meters for a driver to take appropriate action. This situation causes drivers to disregard traffic signs or apply brakes abruptly, an action that may result in accidents. The occurrence of these accidents can be reduced by properly using a road sign alert system. Our study also discovered that, in addition to determining distance, the coordinates’ accuracy check condition has played an important role in providing coordinates that are within a driver’s driving range.Previous works on road signs detection have used colours or images of road signs [16–18]. These approaches faced some challenges such as buffling of images due to a moving vehicle’s vibration; fading of paint on the sign; and occlusion of the sign by obstacles. Other works have used a device on board a vehicle that communicates with an infrastructure installed on the road [20]. This approach also had some challenges such as the devices being expensive and requiring a constant power supply and regular maintenance. The system developed in this study has overcome all these challenges. Also, our developed system has eliminated the need for deploying additional devices on road infrastructure.Our developed system was found to consume more power due to frequent GPS access, which has a negative impact on smartphone batteries. To minimize this challenge, we propose the use of the energy patch framework tool proposed by Benerjee et al., which can reduce energy consumption by 60% [29].


## 4.1. Results

### 4.1.1. Requirements Identification

The first goal of this research was to identify the user and system requirements that could be incorporated into the system. This section presents the findings. The requirements have been classified into two groups: functional and nonfunctional requirements. The details are shown in Tables3–5.(i)
Functional requirementsThe behaviour of the system is defined by functional requirements. This is what the system should do if it is working properly. According to the findings, the developed mobile application should meet the functional requirements outlined in Tables3 and 4.(ii)
The nonfunctional requirementsThe nonfunctional requirements define what the system should be able to do. According to the findings, the developed mobile application should meet the nonfunctional requirements listed in Table5.Table 3
Functional requirements for drivers.
Requirement categoryRequirement descriptionSystem actorSet speed limit notificationThe user should set a speed limit notificationDriverMap visibilityThe system should allow the user to view the mapDriverRoad signsThe system should allow the user to see the road signsDriverReceive alertsThe system should provide notifications timelyDriverSpeed meterThe system should show the speed of the vehicleDriverTable 4
Functional requirements for the system administrator.
Requirement categoryRequirement descriptionSystem actorLogsThe system should show the sensor logsAdministratorView number of requestsThe system should view the number of APIs requests made by usersAdministratorView traffic usageThe system should view daily, weekly, and monthly application traffic usage in web UIAdministratorView error by the responseThe system should view the error reported by the application service response in the web UIAdministratorTable 5
Nonfunctional requirements.
Requirement categoryRequirement descriptionSecurityThe system should authenticate usersResponse timeThe system should respond quickly to user's requestReliabilityThe system should perform the intended tasks for a specific timeUsabilityThe system should be easy to install and simple to useScalabilityThe system should be able to add new featuresRobustnessThe system should function under different circumstances of disturbanceOperating systemThe system should be platform-independent, i.e., android OSPortabilityThe system should operate on android smart devices such as Android car kit TV, android smartphones, android tabletsAvailabilityThe system should be available all the time when requiredPerformanceThe system should perform well under different conditions


### 4.1.2. Implementation Results

(1) System Implementation Results. As shown in Figure 6, the system was designed to run on an Android smartphone, an Android car multimedia player, and an Android tablet. The system has an appealing user interface for both devices, and it responds well to changes in screen size and orientation. A successful installation of the developed application is as simple as opening the APK and following the basic installation steps. Finally, when only an application is used, the user must grant access to storage and location.Figure 6
(a) Destination. (b) Enable access. (c) Speed notification. (d) Map screen. (e) Speed screen. (f) Image alert. (g) Sensor log.
(a)(b)(c)(d)(e)(f)(g)Upon using the developed application, the user must open an application icon. The application will launch, and a route selection prompt will appear as shown in Figure6(a), allowing users to select their intended destination. To enable location tracking, the user must enable location access by turning it on. The home screen contains a button for starting GPS. With this privileged access, GPS will be able to provide real-time coordinates to the mobile device, as shown in Figure 6(b). As shown in Figure 6(c), a set speed notification option button is also found on the home screen. To set a speed limit notification, the user must enable this option. The alarm signals an ascending tone when a speed limit is exceeded. As shown in Figure 6(d), a map screen is used to display a map to the mobile application. This interface displays a map showing the location of road signs. Depending on the route chosen, these visible signs are represented by a small blue and green circle. The blue circles will only appear if the user selects the intended Arusha to Moshi destination, whereas the green circles will only appear if the user selects the intended Moshi to Arusha destination.The signs were integrated with the Google Maps API. This map also shows the user's movement from one location to another. The speed screen displays the current speed of the driver. As shown in Figure6(e), this speedometer has three different colour signals: green, yellow, and red. The green colour represents a safe speed. All speeds less than 80 km/h will be displayed in this colour. This colour indicates that the driver is traveling at the speed recommended by the government for public vehicles. The yellow colour is a warning signal and indicates all speeds greater than 80 km/h but less than 120 km/h. This colour implies that the driver is driving at a high speed. The driver should slow down. The red colour is a danger signal, implying that a driver is traveling at a speed of more than 120 km/h. The driver should slow down.Alerts about road signs are provided by voice messages and road sign images. When drivers are within a close range of 250 meters before the road signs, valuable information is immediately conveyed to them. The voice is provided by a female voice agent. The female voice was more familiar to the participants because it was widely used in smartphones navigation systems. In addition, in a noisy environment, the female voice is easier to hear than the male voice. The image of the road sign will be displayed, as shown in Figure6(f).Figure6(g) shows the sensor logs written when an alert is immediately released. The log file contains important information such as the distance over which alerts were issued, specific coordinates when alerts were issued, and the accuracy of the coordinates released. The file also contains a specific type of alert released, date, and time as tangible proof that the appropriate notification was released.(2) Results of Web Application (Google Cloud Platform) Implementation. To timely monitor user traffic on an application, a Google cloud platform web application tool was integrated with our mobile application. The platform offers an important tool and API service for managing applications. The system cloud dashboard provides a convenient summary of cloud reports from mobile users to the system administrator. The dashboard provides a high-level view of the state of the mobile application, including the number of requests made, traffic responses, and latency. Additionally, errors reported by the cloud are also indicated. Furthermore, the security of access to information has been restricted to prevent unauthorized data sharing. By doing so, the mobile application was secured by limiting access to the API key. The method includes the application package as well as the Secure Hash Algorithm (SHA-1) signing certificate fingerprint.


### 4.1.3. Resource Utilization Results

An Android profiler is a useful tool in Android Studio that provides real-time application information such as CPU usage, efficient memory allocation, active network, and battery. A Nokia 7.2 was used in this experiment to determine the resources used by a mobile application. This valuable information is used to optimize the performance of the potential application by identifying outstanding performance-related issues.The developed system was installed on a smartphone (Nokia 7.2, Android 10 API Level 29, Octa-core (4 × 2.2 GHz), 6 GB RAM, Li-Po 3500 mAh nonremovable battery, IPS LCD 6.3 inches). While driving a vehicle along a predetermined route, the smartphone was connected to a PC that visually tracked the resources. The raw data of resource utilization were being monitored in real-time. We evaluated our mobile application based on two activities: background and foreground. The goal was to visualize the instant energy consumption of the potential application when running on a smartphone. When the system was running, areas in which the application makes inefficient use of resources were identified. We reveal what happens during the successful execution of the application in the foreground and background. In both cases, we display the graphs of energy utilization when using the developed application.(i)
Foreground Activities ResultsFigure7 shows the results of the foreground activities measurements on the Android device. The results show a significant percentage of CPU, Memory, and Energy usage as follows.(a)
CPU usageThe CPU usage profile has the distinct advantage of displaying how specific functions consume CPU percentage time. The process helps to properly understand how the mobile application is executed and how valuable resources are allocated correctly. CPU usage was measured using an Android profiler tool, as shown in Figure7. The results show that the application CPU usage contributes to 12% of the total system CPU usage when the system is running.(b)
Memory usageA memory profile in the Android profiler is used to correctly identify the memory usage of applications. The critical component displays a real-time utilization of the running application, which aids in the detection of application memory leaks, freezing, and crashing. The memory utilization was measured as shown in Figure7. It was found that the application uses a total of 261 MB of memory, and graphics contributes a significant chunk of that usage.(c)
Energy usageThe energy profile in Android Profiler is used to correctly identify the energy usage of applications. It employs a model that estimates the amount of energy consumed by each resource. The CPU, network, radio, and GPS sensors are all monitored by the tool. Also, it provides a variety of points of interest, such as searching for issues related to unnecessary energy usage. We examined our application’s energy utilization activities, which cause battery drain and excess power consumption to stay awake. The usage was measured as shown in Figure7. It was found that the application contributes a light amount of energy usage. However, system events such as frequent location requests and speed determination contributed to significant energy consumption. The GPS sensor consumes a significant amount of energy while listening to and updating a location request. Furthermore, energy consumption becomes high as the sensor calculates speed when a vehicle navigates from one point to another.(ii)
Background Activities ResultsFigure8 shows the results of the background activities measurements on the Android device. The mobile application was minimized and allowed to run in the background to evaluate the activities. The results show that the CPU usage drops to 1%. The energy profile shows a low energy usage. Furthermore, the application memory usage was reduced to 227 MB of memory, the system killed some processes that consumed a significant amount of RAM, and the main activity was immediately terminated. During the application execution, the most recent data about the navigation screen could not be refreshed in some rare cases, and the application was required to restart.Figure 7
Foreground activities resources utilization.Figure 8
Background activities resource utilization.Based on the results of the experiments, we can conclude that running a mobile application in the background consumes less energy for each resource on a mobile device. However, the application cannot provide better performance in terms of providing drivers with the latest navigation updates and road sign notifications.(1) Evaluation. The performance output of a mobile application on mobile devices varies depending on its practical use. In this experiment, the evaluation was carried out when the mobile application was running in the foreground and background. This experiment was carried out solely to demonstrate the importance of these fundamental concepts.Based on the results of the experiments, we can conclude that running the application in the foreground results in better performance in providing appropriate notifications to the mobile application users. The mobile application runs at high frequency, and the appropriate notifications are gradually released over a long period of time at a safe distance within 250 meters. Most of the time, the GPS sensor uses a significant amount of energy while listening to and updating a location request. This system may have a limitation that affects resources such as energy, memory, and CPU on any mobile device’s power consumption. When a mobile application is minimized, it produces better resource performance indicators than when it is in the foreground. However, in some cases, the most recent data about the navigation screen could not be refreshed, necessitating a restart.


## 4.1.1. Requirements Identification

The first goal of this research was to identify the user and system requirements that could be incorporated into the system. This section presents the findings. The requirements have been classified into two groups: functional and nonfunctional requirements. The details are shown in Tables3–5.(i)
Functional requirementsThe behaviour of the system is defined by functional requirements. This is what the system should do if it is working properly. According to the findings, the developed mobile application should meet the functional requirements outlined in Tables3 and 4.(ii)
The nonfunctional requirementsThe nonfunctional requirements define what the system should be able to do. According to the findings, the developed mobile application should meet the nonfunctional requirements listed in Table5.Table 3
Functional requirements for drivers.
Requirement categoryRequirement descriptionSystem actorSet speed limit notificationThe user should set a speed limit notificationDriverMap visibilityThe system should allow the user to view the mapDriverRoad signsThe system should allow the user to see the road signsDriverReceive alertsThe system should provide notifications timelyDriverSpeed meterThe system should show the speed of the vehicleDriverTable 4
Functional requirements for the system administrator.
Requirement categoryRequirement descriptionSystem actorLogsThe system should show the sensor logsAdministratorView number of requestsThe system should view the number of APIs requests made by usersAdministratorView traffic usageThe system should view daily, weekly, and monthly application traffic usage in web UIAdministratorView error by the responseThe system should view the error reported by the application service response in the web UIAdministratorTable 5
Nonfunctional requirements.
Requirement categoryRequirement descriptionSecurityThe system should authenticate usersResponse timeThe system should respond quickly to user's requestReliabilityThe system should perform the intended tasks for a specific timeUsabilityThe system should be easy to install and simple to useScalabilityThe system should be able to add new featuresRobustnessThe system should function under different circumstances of disturbanceOperating systemThe system should be platform-independent, i.e., android OSPortabilityThe system should operate on android smart devices such as Android car kit TV, android smartphones, android tabletsAvailabilityThe system should be available all the time when requiredPerformanceThe system should perform well under different conditions


## 4.1.2. Implementation Results

(1) System Implementation Results. As shown in Figure 6, the system was designed to run on an Android smartphone, an Android car multimedia player, and an Android tablet. The system has an appealing user interface for both devices, and it responds well to changes in screen size and orientation. A successful installation of the developed application is as simple as opening the APK and following the basic installation steps. Finally, when only an application is used, the user must grant access to storage and location.Figure 6
(a) Destination. (b) Enable access. (c) Speed notification. (d) Map screen. (e) Speed screen. (f) Image alert. (g) Sensor log.
(a)(b)(c)(d)(e)(f)(g)Upon using the developed application, the user must open an application icon. The application will launch, and a route selection prompt will appear as shown in Figure6(a), allowing users to select their intended destination. To enable location tracking, the user must enable location access by turning it on. The home screen contains a button for starting GPS. With this privileged access, GPS will be able to provide real-time coordinates to the mobile device, as shown in Figure 6(b). As shown in Figure 6(c), a set speed notification option button is also found on the home screen. To set a speed limit notification, the user must enable this option. The alarm signals an ascending tone when a speed limit is exceeded. As shown in Figure 6(d), a map screen is used to display a map to the mobile application. This interface displays a map showing the location of road signs. Depending on the route chosen, these visible signs are represented by a small blue and green circle. The blue circles will only appear if the user selects the intended Arusha to Moshi destination, whereas the green circles will only appear if the user selects the intended Moshi to Arusha destination.The signs were integrated with the Google Maps API. This map also shows the user's movement from one location to another. The speed screen displays the current speed of the driver. As shown in Figure6(e), this speedometer has three different colour signals: green, yellow, and red. The green colour represents a safe speed. All speeds less than 80 km/h will be displayed in this colour. This colour indicates that the driver is traveling at the speed recommended by the government for public vehicles. The yellow colour is a warning signal and indicates all speeds greater than 80 km/h but less than 120 km/h. This colour implies that the driver is driving at a high speed. The driver should slow down. The red colour is a danger signal, implying that a driver is traveling at a speed of more than 120 km/h. The driver should slow down.Alerts about road signs are provided by voice messages and road sign images. When drivers are within a close range of 250 meters before the road signs, valuable information is immediately conveyed to them. The voice is provided by a female voice agent. The female voice was more familiar to the participants because it was widely used in smartphones navigation systems. In addition, in a noisy environment, the female voice is easier to hear than the male voice. The image of the road sign will be displayed, as shown in Figure6(f).Figure6(g) shows the sensor logs written when an alert is immediately released. The log file contains important information such as the distance over which alerts were issued, specific coordinates when alerts were issued, and the accuracy of the coordinates released. The file also contains a specific type of alert released, date, and time as tangible proof that the appropriate notification was released.(2) Results of Web Application (Google Cloud Platform) Implementation. To timely monitor user traffic on an application, a Google cloud platform web application tool was integrated with our mobile application. The platform offers an important tool and API service for managing applications. The system cloud dashboard provides a convenient summary of cloud reports from mobile users to the system administrator. The dashboard provides a high-level view of the state of the mobile application, including the number of requests made, traffic responses, and latency. Additionally, errors reported by the cloud are also indicated. Furthermore, the security of access to information has been restricted to prevent unauthorized data sharing. By doing so, the mobile application was secured by limiting access to the API key. The method includes the application package as well as the Secure Hash Algorithm (SHA-1) signing certificate fingerprint.


## 4.1.3. Resource Utilization Results

An Android profiler is a useful tool in Android Studio that provides real-time application information such as CPU usage, efficient memory allocation, active network, and battery. A Nokia 7.2 was used in this experiment to determine the resources used by a mobile application. This valuable information is used to optimize the performance of the potential application by identifying outstanding performance-related issues.The developed system was installed on a smartphone (Nokia 7.2, Android 10 API Level 29, Octa-core (4 × 2.2 GHz), 6 GB RAM, Li-Po 3500 mAh nonremovable battery, IPS LCD 6.3 inches). While driving a vehicle along a predetermined route, the smartphone was connected to a PC that visually tracked the resources. The raw data of resource utilization were being monitored in real-time. We evaluated our mobile application based on two activities: background and foreground. The goal was to visualize the instant energy consumption of the potential application when running on a smartphone. When the system was running, areas in which the application makes inefficient use of resources were identified. We reveal what happens during the successful execution of the application in the foreground and background. In both cases, we display the graphs of energy utilization when using the developed application.(i)
Foreground Activities ResultsFigure7 shows the results of the foreground activities measurements on the Android device. The results show a significant percentage of CPU, Memory, and Energy usage as follows.(a)
CPU usageThe CPU usage profile has the distinct advantage of displaying how specific functions consume CPU percentage time. The process helps to properly understand how the mobile application is executed and how valuable resources are allocated correctly. CPU usage was measured using an Android profiler tool, as shown in Figure7. The results show that the application CPU usage contributes to 12% of the total system CPU usage when the system is running.(b)
Memory usageA memory profile in the Android profiler is used to correctly identify the memory usage of applications. The critical component displays a real-time utilization of the running application, which aids in the detection of application memory leaks, freezing, and crashing. The memory utilization was measured as shown in Figure7. It was found that the application uses a total of 261 MB of memory, and graphics contributes a significant chunk of that usage.(c)
Energy usageThe energy profile in Android Profiler is used to correctly identify the energy usage of applications. It employs a model that estimates the amount of energy consumed by each resource. The CPU, network, radio, and GPS sensors are all monitored by the tool. Also, it provides a variety of points of interest, such as searching for issues related to unnecessary energy usage. We examined our application’s energy utilization activities, which cause battery drain and excess power consumption to stay awake. The usage was measured as shown in Figure7. It was found that the application contributes a light amount of energy usage. However, system events such as frequent location requests and speed determination contributed to significant energy consumption. The GPS sensor consumes a significant amount of energy while listening to and updating a location request. Furthermore, energy consumption becomes high as the sensor calculates speed when a vehicle navigates from one point to another.(ii)
Background Activities ResultsFigure8 shows the results of the background activities measurements on the Android device. The mobile application was minimized and allowed to run in the background to evaluate the activities. The results show that the CPU usage drops to 1%. The energy profile shows a low energy usage. Furthermore, the application memory usage was reduced to 227 MB of memory, the system killed some processes that consumed a significant amount of RAM, and the main activity was immediately terminated. During the application execution, the most recent data about the navigation screen could not be refreshed in some rare cases, and the application was required to restart.Figure 7
Foreground activities resources utilization.Figure 8
Background activities resource utilization.Based on the results of the experiments, we can conclude that running a mobile application in the background consumes less energy for each resource on a mobile device. However, the application cannot provide better performance in terms of providing drivers with the latest navigation updates and road sign notifications.(1) Evaluation. The performance output of a mobile application on mobile devices varies depending on its practical use. In this experiment, the evaluation was carried out when the mobile application was running in the foreground and background. This experiment was carried out solely to demonstrate the importance of these fundamental concepts.Based on the results of the experiments, we can conclude that running the application in the foreground results in better performance in providing appropriate notifications to the mobile application users. The mobile application runs at high frequency, and the appropriate notifications are gradually released over a long period of time at a safe distance within 250 meters. Most of the time, the GPS sensor uses a significant amount of energy while listening to and updating a location request. This system may have a limitation that affects resources such as energy, memory, and CPU on any mobile device’s power consumption. When a mobile application is minimized, it produces better resource performance indicators than when it is in the foreground. However, in some cases, the most recent data about the navigation screen could not be refreshed, necessitating a restart.


## 4.2. Discussion

This study developed an Android mobile application for drivers as a tool to help them determine the upcoming road signs at an appropriate distance. The system's potential benefit is enhancing vehicle safety by providing real-time traffic information to the user.The study found that at 250 meters before reaching a road sign, drivers have enough time to act appropriately. Despite the presence of road signs on most Tanzanian highways, the placement of these signs requires careful thought and planning. Road signs must be carefully placed at the farthest distance ahead of the intended warning. Static road signs are frequently seen too late at a certain close range of 10–50 meters for a driver to take appropriate action. This situation causes drivers to disregard traffic signs or apply brakes abruptly, an action that may result in accidents. The occurrence of these accidents can be reduced by properly using a road sign alert system. Our study also discovered that, in addition to determining distance, the coordinates’ accuracy check condition has played an important role in providing coordinates that are within a driver’s driving range.Previous works on road signs detection have used colours or images of road signs [16–18]. These approaches faced some challenges such as buffling of images due to a moving vehicle’s vibration; fading of paint on the sign; and occlusion of the sign by obstacles. Other works have used a device on board a vehicle that communicates with an infrastructure installed on the road [20]. This approach also had some challenges such as the devices being expensive and requiring a constant power supply and regular maintenance. The system developed in this study has overcome all these challenges. Also, our developed system has eliminated the need for deploying additional devices on road infrastructure.Our developed system was found to consume more power due to frequent GPS access, which has a negative impact on smartphone batteries. To minimize this challenge, we propose the use of the energy patch framework tool proposed by Benerjee et al., which can reduce energy consumption by 60% [29].


## 5. Conclusion

Road accidents cannot be eliminated but can be reduced by enhancing the safety of the drivers. This study developed a smart mobile-based application that uses in-built sensors to alert drivers with voice and image notifications. The application provides a voice alert to a needed action that enhances the driver’s attention. The smartphone is used to avoid the need for onboard devices to detect and recognize road signs, sensors on road infrastructure, and the use of WLAN. We have used the Haversine formula for measuring and estimating the distance between two pairs of coordinates. According to the experimental results, the proposed methodology has the benefits of high accuracy within a user radius of 10 meters, minimum bandwidth, and low-cost application. All notifications are released in a close range of 250 meters before the actual signs. Furthermore, the system administrator can monitor the system by using a cloud dashboard. The dashboard provides reports such as the number of requests made by users, errors, and traffic responses. Moreover, the system is secured to avoid unauthorized access to sensitive information. The security key was generated and added to the manifest file of the application and only requests made with the API key authenticate each user of the system. This research has generated information that can be utilized by future works in developing similar systems.


### 5.1. Recommendation

The study was small in scale; hence, it is difficult to generalize the findings. Future works should use large samples. Also, future studies should use alternative methods that identify and modifies a specific class of energy inefficiencies.


## 5.1. Recommendation

The study was small in scale; hence, it is difficult to generalize the findings. Future works should use large samples. Also, future studies should use alternative methods that identify and modifies a specific class of energy inefficiencies.



---

*Source: 5829607-2022-04-21.xml*