The Dashboard of Remote Monitoring System for Driver Fatigue

Chapter 2 discusses driving safety, which is a major issue worldwide with many traffic fatalities each year. Human factors such as fatigue and cell phone distraction are often to blame; in Indonesia, driver negligence accounts for 61% of accidents [1]. This chapter also discusses traditional methods of monitoring drivers, such as the use of sensors to determine if drivers are tired. However, these methods often fail under light and cannot spot additional distractions such as cell phones or smoking. AI and YOLOv8 technology can detect risky behavior more accurately [3].

In this system, driver behavior data is obtained through visual detection using the YOLOv8 algorithm, which has proven effective in identifying facial features such as closed eyes, head tilt, and yawning in real-time. Recent research by Zhang and Zhang [6] demonstrated that an optimized YOLOv8 model can detect driver drowsiness with high accuracy and real-time performance exceeding 50 FPS, making it highly suitable for in-vehicle applications.

The detected data is then integrated into a web-based system using WebSocket technology. WebSocket enables direct, bidirectional communication between the server and the user interface without requiring page reloads, which is essential for delivering instant feedback in driver monitoring systems. Studies have shown that WebSocket is particularly effective in real-time applications due to its low latency and persistent connection capabilities [7].

2.1 Driving safety and traffic accidents

Traffic accidents are still the leading cause of death and injury in the world, making driving safety a growing problem worldwide. According to the World Health Organization (WHO), traffic accidents cause more than 1.3 million deaths each year. Human factors such as smoking, drowsiness, and mobile phone distraction are the main causes of many accidents [1]. According to Korlantas Polri, driver negligence, including fatigue and cell phone distraction, accounts for 61% of traffic accidents in Indonesia. This suggests that drivers increase the risk of accidents as they are often unable to detect or identify danger signs [2].

2.2 Traditional methods of driver monitoring

The use of vehicle-based sensors and manual surveillance are two conventional ways to monitor driver behavior. Sensors based on physical measurements such as Eye Aspect Ratio (EAR) are used to detect driver fatigue. While these systems detect one driver behavior, such as fatigue, they cannot detect other non-physical behaviors, such as mobile phone distraction or smoking. According to research, these sensors often fail in more complex situations or with poor lighting [3]. In addition, manual surveillance requires constant supervision from an operator or supervisor, which can increase workload and increase the likelihood of human error.

Attention will increasingly focus on the use of Artificial Intelligence and computer vision to detect driver behavior. Algorithms such as YOLOv8-also known as You Only Look Once Version-are able to detect and classify objects in images in real-time with a higher degree of accuracy even in low lighting conditions. YOLOv8, which is widely used in computer vision applications, can detect a variety of behaviors that could endanger drivers, such as fatigue, mobile phone use, and smoking [8]. The system utilizes images captured from vehicle cameras to provide feedback and information about the driver's status instantly [9]. Deep learning and Convolutional Neural Networks (CNN) are also used in driver monitoring applications, such as YOLO. CNNs can identify more complex behavioral patterns and symptoms of fatigue or other impairments. Compared to traditional methods, these technologies can be more accurate in finding different types of risky behaviors [10].

2.3 Backend integration and real-time detection system

For driver monitoring systems, real-time integration of data from multiple sensor sources to the backend is a key issue. Many current systems rely on separate external sensors, resulting in delayed data delivery to the driver or vehicle operator. By ensuring fast delivery of feedback, cloud-based systems that use Socket.IO or REST APIs can solve this problem. Socket.IO allows data to communicate between the frontend and backend in real-time without the need to switch pages, improving system responsiveness [11]. This integration is crucial to ensure that drivers receive important information immediately and can take precautions.

Data security and privacy in driver monitoring applications is critical as the data collected can be highly sensitive. To protect user data, the use of technologies such as JSON Web Token (JWT) for authentication and API keys to ensure authorized access is essential. These systems guarantee that only identified persons can access the driver's personal data and related information [5].

This chapter presents the test results of the web-based driver behavior detection and notification system through the Telegram application. The tests were conducted in a laboratory using simulated drivers to test the efficacy of the system in detecting signs of driver fatigue and non-compliance. The system being tested is YOLO v8, a deep learning-based object detection model that can detect various important parameters, including eye condition, mouth movements, head position, and yawning, which is the term for nodding or yawning. In addition, the test will include Telegram alerts that will be sent to drivers and vehicle operators in real-time if the system finds signs of negligence or drowsiness in driving behavior.

It should be noted that these tests have not been conducted in the field, so additional testing on drivers in real-life situations is needed to more accurately assess the system's performance. Testing in real-life situations will help assess the system's performance in the face of external variables such as environmental disturbances or more complex driver behaviors. The results of these laboratory tests show that the web-based driver fatigue detection and real-time notification technology has great potential for use. However, additional testing is needed to ensure that the system can operate well in more complex and dynamic work.

4.1 Notifications delivery time testing

In the first test, measurements were taken to measure the time to send notifications to the system when the driver's status on the web changed to “sleepy”. The purpose of this test was to measure the responsiveness of the system in alerting the driver and vehicle operator in real time. Parameters such as eye condition, head position, mouth movement, and yawning-or nodding or yawning-were used in the tested system to detect signs of driver fatigue. If the driver system detects drowsiness, the status on the web interface will change to “drowsy”, and a notification will be sent via the Telegram app. This test measured and recorded the time taken for the notification to be sent. As part of the system evaluation, a series of ten trials were conducted to verify the consistency of notification delivery under various conditions. The test results showed that the speed of notification delivery and the accuracy of the system to identify the driver's status were excellent. Furthermore, the test data was evaluated and compared with the previous test results discussed in section 4.2 which tested the system's performance in more complex situations. As such, this test also provides an overview of the stability of the system in operating under real-time conditions as well as potential enhancements needed to improve the responsiveness of the system.

11.jpg

Figure 11. Response time for telegram notification delivery

Figure 11, In the first test, the main objective was to measure the notification delivery time when the status is changed to “sleepy” in the system. In this test, the system is programmed to detect certain conditions, such as a change in user status, and then send the relevant notification. The graph depicts the response time in seconds at 10 different data points, where each data point represents the time taken by the system to send and process the notification. The test results show that the response time is relatively consistent from Data 1 to Data 9, ranging from 0.8 to 1 second. This reflects the efficiency of the system in managing notification requests under normal conditions.

12.jpg

Figure 12. Telegram notification

Figure 12, however, in Data 10 there is a significant spike in response time, reaching more than 1 second. This spike could be caused by several factors, such as increased system load, network delays, or less efficient management of the notification queue. Overall, although the system showed stable response times in most of the tests, the spike in Data 10 indicates a bottleneck or technical issue that needs to be analyzed further.

To improve the efficiency of the system, it is necessary to further analyze the cause of the spike on Data 10, including evaluating server availability, queue management, and network conditions. Future tests could involve simulations with a larger number of notifications to test how the system handles higher loads.

13.jpg

Figure 13. Notification logic flow from detection to telegram alert delivery

Figure 13, the telegram notification mechanism is activated after the detection data is processed and successfully stored in the database. The system first verifies whether the WebSocket connection (detectionend) has been properly initialized. If the connection is active, a new_detection event is emitted to the frontend to update the dashboard interface in real time. If the WebSocket is not available, the system logs a warning and skips the emission process to prevent runtime errors.

Subsequently, the system constructs a structured message containing key detection parameters, including the driver ID, eye and mouth conditions, drowsiness status, and the start and end timestamps of the detection event. This message is then passed to the sendTelegramAlert() function, which delivers the alert to a designated Telegram chat using the Telegram Bot API.

This logic ensures that notifications are only sent when valid detection data is available and the system is in a stable operational state. Furthermore, it prevents unnecessary alerts by verifying the readiness of the communication channel before attempting to emit or notify. This approach enhances the reliability of the alert system and minimizes the risk of false or redundant notifications.

4.2 Testing to obtain drowsiness condition parameter responses

This test measures driver drowsiness by monitoring the following parameters: Driver ID for driver identification, Eye State for eye state (open or closed), Mouth State for mouth state (open or closed), Head Pose for head position (normal or tilted), Yawning to measure whether the driver yawns, Drowsiness Status to indicate whether the driver is sleepy, and Start Time, End Time, and Duration to record the start, end, and duration times of the test. These parameters are used to assess the drowsiness level of the driver.

In Table 1 present the result of the test, which recorded in this table aims to measure the response time of sending data related to the drowsiness state of driver D001. Each row records data about the driver indicating drowsiness, with parameters such as eyes closed, mouth open, yawning (true), and drowsy status. The data also records varying head positions of the driver, such as normal, tilted, and slightly tilted head positions, which can indicate fatigue or inattention. The test duration for each data varies from 5 to 12 seconds.

Table 1. Data sending test results

Each line shows a “Success” status after successful data transmission. For data transmission, milliseconds (ms) are used to indicate the response time, which ranges from 9 ms to 106 ms. A faster response time, such as 9 ms, indicates faster processing, while a longer response time, such as 106 ms, indicates that data transmission takes a little more time, although it remains within an acceptable range. Overall, these tests were successful; they demonstrated the system's ability to send and process data in a relatively quick time, which suggests that the system is quite effective at identifying driver drowsiness.

4.3 Dashboard testing

In Figure 14, In the dashboard section, tests were conducted to monitor the driver's drowsiness condition using several parameters, which were then displayed in tabular form on the dashboard of the driver behavior detection system. The data displayed in the table includes various attributes related to the driver's drowsiness status, such as Driver ID, Eye State, Mouth State, Head Pose, Yawning, Drowsiness Status, Start Time, End Time, and Duration. From the table shown, it can be seen that driver D001 experienced a drowsy condition in each test conducted. In each row, the drowsiness_status shows the value “Drowsy”, which means the driver is in a drowsy condition. This can be seen from several parameters such as Eye State which shows closed eyes, and yawning which indicates the driver is yawning.

14.jpg

Figure 14. Dashboard Monitoring

The test duration varies between 5 to 12 seconds. This shows that the system can detect driver drowsiness in a relatively short time. Although there is a slight variation in duration, the overall system shows good responsiveness to the driver's drowsy state.

In Figure 15, Testing on the POST detection endpoint was performed with 100 iterations, resulting in a total test duration of 8 seconds 720 milliseconds (8s 720ms). During the test, all requests were successfully processed with a response status of 200, indicating that there were no errors in any of the API requests. The average response time for each request was 20 milliseconds, indicating that the API responded very quickly. The time distribution diagram also shows that most requests completed within a short time, with little variation in response duration. These test results show that the API works efficiently, can handle the test load well, and provides fast and stable results.

15.jpg

Figure 15. Post-detection API test summary and response times

In Figure 16, Testing on the GET detection endpoint was conducted with 100 iterations, resulting in a total test duration of 8 seconds 794 milliseconds (8s 794ms). During the test, all requests were successfully processed with a response status of 200, indicating that the API worked well and as expected. The average response time for each request was 7 milliseconds, indicating that the API is very efficient in providing responses. The time distribution diagram shows that most requests completed with very fast and stable response times, with no major fluctuations in duration. These test results show that the API on the GET detection endpoint has excellent performance, responsiveness, and stability.

16.jpg

Figure 16. Get-detection API test summary and response times

4.4 User registration process with data security using hashing

In Figure 17, figure explanation the application of hashing is very important in securing user data in the sign-in and sign-up system. In the view shown in figure, this is the sign-up page for a new user, in this case an admin. The user is required to enter a name, email, and password to create an account. After registering, the data entered will be automatically sent to the server. One important step is that the entered password will be converted into a hash value using a secure algorithm such as bcrypt or SHA-256. This hashing process converts the original password into a random string that cannot be restored to its original form. This aims to keep in mind that even if the database is accessed by unauthorized parties, they will only see the hash value and not the original password which can be misused.

17.jpg

Figure 17. User registration page for secure data access

In Figure 18, shows a view of the database that stores registered user data. The password column indicates that the value stored is not the original password entered by the user, but the hash value generated from the hashing process. For example, in the first row, the password entered by the user has been converted into a long random string. This is the result of the hashing algorithm applied at the time of sign-up. With this method, even if this database is accessed by unauthorized parties, they will not be able to know the user's original password as only the hash value is visible. This strengthens the security of user data by preventing the theft of sensitive data such as passwords. The created_at field indicates the time of account creation, which can be used to track when the account was created.

18.jpg

Figure 18. Database entry for user encrypted password

The application of this hashing technique ensures that the data stored in the database is safe from unauthorized access, maintains user privacy, and prevents potential misuse of personal data.

In Figure 19, shows a comparison of user data that has a password in plain text or plaintext without hashing technology. In this case, the password in the password field is the same as the user entered, i.e. 12345678. This shows that this password is no longer protected. Since the database is stored in an easily accessible format, the password can be easily read and misused if an unauthorized party is able to access it.

19.jpg

Figure 19. Database entry for user with plaintext password

4.5 Performance testing

In Figure 20 illustrates the response time graph obtained during a 10-minute performance testing session. This test was designed to evaluate the responsiveness of both the REST API endpoints and the WebSocket communication channel under varying virtual user loads. The number of simulated users was gradually increased from 20 to 100 and then decreased back to 20, while monitoring the system’s ability to handle concurrent requests and real-time data transmission.

20.jpg

Figure 20. Performance

The graph shows that the average response time (represented by the blue line) remained relatively stable during most of the test duration. However, significant spikes in response time were observed as the number of concurrent users increased. The first noticeable spike occurred around 15:00:40, coinciding with the initial rise in user load. The most substantial spike was recorded at 15:01:28, when the system reached its peak load of 100 users. At this point, the response time exceeded 10,000 milliseconds (10 seconds), as indicated by the sharp rise in the 95th and 99th percentile lines.

These results suggest that while the system performs efficiently under normal conditions, it encounters performance bottlenecks during peak load, particularly in handling simultaneous WebSocket messages and REST API requests. Once the load was reduced, the response time stabilized, indicating the system’s ability to recover after high-stress conditions.

This test highlights the need for further optimization, such as implementing load balancing, asynchronous processing, or message queuing, to enhance the system’s scalability and ensure consistent performance under high concurrency.

4.6 Comparative analysis with existing

This test highlights the need for further optimization, such as implementing load balancing, asynchronous processing, or message queuing, to enhance the system’s scalability and ensure consistent performance under high concurrency.

To evaluate the effectiveness of the proposed driver fatigue monitoring system, a comparative analysis was conducted against existing systems that utilize traditional sensor-based methods and earlier versions of computer vision models such as YOLOv5. The comparison focuses on key performance indicators including detection accuracy, response time, real-time feedback capability, and system scalability.

In Table 2, The proposed system demonstrates competitive performance in terms of detection accuracy and response speed. The YOLOv8 model employed in this system was pre-trained to recognize driver behaviors such as eye closure, yawning, and head posture. The training dataset was sourced from the publicly available Roboflow platform, comprising 3,474 annotated images of drivers captured under diverse conditions, including varying lighting, camera angles, and the presence of accessories such as glasses and masks. The dataset was partitioned into 87% for training, 8% for validation, and 4% for testing. Data augmentation techniques were applied to enhance generalization, including rotation, zoom, shear, color adjustments, blur, and noise. The model was trained using an input resolution of 416×416 pixels and achieved a mean Average Precision (mAP), precision, and recall of 99.3%, indicating highly reliable detection performance for real-time monitoring and alert delivery via the integrated dashboard and Telegram notification service [31].

Table 2. Comparative analysis

YOLOv5-based systems trained on facial features such as eye closure and yawning achieve approximately 73.7% accuracy in detecting driver drowsiness, but it is limited in responsiveness and adaptability to varying lighting conditions. In contrast, traditional sensor-based systems relying on Eye Aspect Ratio (EAR) or steering pressure typically reach around 70-75% accuracy and are less suitable for real-time applications due to their intrusive nature and lack of contextual awareness [31, 32].

These findings highlight the superior performance of the proposed YOLOv8-based system in both accuracy and responsiveness, making it a more viable solution for real-world deployment in dynamic driving environments.

4.7 Eror source and statical validation

Despite the high accuracy and responsiveness demonstrated by the proposed driver fatigue monitoring system, several factors may introduce variability or error in detection outcomes. These factors must be critically examined to ensure the robustness and reliability of the system in diverse operational environments.

One of the primary sources of error is lighting conditions. Inadequate or uneven illumination can significantly impair the visibility of facial features, particularly the eyes and mouth, which are essential for detecting signs of drowsiness. Similarly, occlusions caused by accessories such as eyeglasses, face masks, or headwear may obstruct key facial landmarks, leading to misclassification or missed detections.

Another contributing factor is the camera angle and resolution. Improper camera placement or low-resolution video input can reduce the precision of the YOLOv8 detection model, especially when subtle facial movements are involved. Furthermore, driver variability—including differences in facial structure, behavioral patterns, and expressions of fatigue—can affect the generalization capability of the model across different individuals.

Table 3, To evaluate the consistency of the system’s performance, a statistical analysis was conducted using response time data collected from ten trials of drowsiness detection and notification delivery. The results are presented in Table 3.7. The analysis yielded a mean response time of 0.91 seconds and a standard deviation of 0.09 seconds, indicating a high level of consistency across trials. These findings suggest that the system performs reliably under controlled laboratory conditions.

For future work, it is recommended to incorporate more advanced statistical validation techniques, such as hypothesis testing and confidence interval analysis, to further substantiate the significance of the experimental results. Additionally, field testing under varied environmental conditions and with a broader demographic of drivers will be essential to assess the system’s robustness and scalability in real-world applications.

Table 3. Performance consistency test