Real-time Aggressive Driving Detection System based on In-vehicle Information using LoRa Communication

Safe driving has attracted a significant amount of attention in recent years owing to the increase in the complexity of the driving environment. There are many research studies focusing on detection of aggressive driving that may cause traffic accidents. In this paper, we propose a system for acquiring vehicles’ interior data and thereby detecting dangerous driving conditions. The system is designed to transmit the information acquired to a data server using Long Range (LoRa) communication networks. Through experimentation, we confirm that the proposed system can detect aggressive driving behaviors in real time and store them on the data server through LoRa communication. We evaluated techniques for acquiring in-vehicle information on 14 vehicles and confirmed that data can be extracted from most of the commonly available vehicles.


Introduction
As society develops, the number of vehicles on the road increases and the driving environment becomes increasingly complex. According to the statistics of traffic accidents provided by the Korean National Police Agency, more than 200,000 traffic accidents and about 5,000 deaths occur each year. Many studies related to safe driving have been performed. Some examples include systems such as intelligent transportation system (ITS) and advanced driver assistant system (ADAS) which assist in driving by performing additional safe driving functions. Technologies that are currently under active research and development include forward collision warning (FCW), lane departure warning (LDW), and pedestrian detection systems.
Research is also underway to analyze the driving behaviors of drivers. This research aims to prevent traffic accidents by detecting driving behavior that is likely to cause accidents and notifying the driver of their occurrence. By applying the technique detailed in this study, the driving habits of drivers and the frequency of dangerous driving incidents can be analyzed. Car insurance companies already use this information to sell user-specific insurance products. In order to analyze a driver's driving behavior, various pieces of information are required such as vehicle environment/surrounding conditions, vehicle status and operation information. The vehicle's environment information includes data regarding the surrounding environment of the target vehicle, such as the number of lanes on the road, number of surrounding vehicles, and the speed of traffic. The vehicle state information includes the movement data about the vehicle, including the direction, speed, and acceleration of the vehicle. Finally, the vehicle operation information is information detailing how the driver controls the vehicle, and monitors acceleration pedal, brake pedal, steering wheel and turn signal operations.
In existing driver behavior analysis systems, owing to the difficulty in acquiring vehicle operation information, only the vehicle state information is often used. These systems use acceleration sensors to acquire the speed and acceleration information of the vehicle and detect dangerous driving behaviors, such as sudden starts or stops. However, certain types of aggressive driving behaviors, such as threatening lane changes, are difficult to detect. Certain applications such as user-specific insurance require only vehicle operation information. In the existing driver behavior analysis systems, the driver directly influences the results of the driving behavior analysis. Therefore, existing systems are not compatible with other application systems. In other words, drivers who want to take advantage of a variety of safe driving application systems are forced to use multiple devices or use only driver behavior analysis systems.
The proposed system not only periodically transmits vehicle operation information to the server using Long Range (LoRa) communication, but also analyzes the information and displays the level of dangerous driving on the driver's smartphone in real time. When certain dangerous driving behaviors are detected, an alarm is triggered to alert the driver of the driving behavior.
The second chapter of this paper introduces the research related to the analysis of existing driver behaviors. Section 3 describes the proposed system, and Section 4 evaluates the performance of the proposed system. In Section 5, we state our conclusions regarding our system, methods, and required future work.

Related work
Currently, there is a great amount of research being conducted that analyzes the driving behavior of drivers. Research studies focusing on driving behavior are actively being conducted using vehicle status information, machine learning and deep learning technologies. Lee [1] classified driving events using vehicle speed, acceleration, and yaw rate. To aid in classification, machine learning techniques such as auto encoder and self-organizing map (SOM) are used. This study clustered 32 driving styles and defined some of the specific clusters as dangerous driving behaviors. Chen [2] analyzed the driver's left turn and right turn characteristics by using an inertial measurement unit (IMU) sensor. They identified the driver by observing specific features during turning operations. Acceleration along the end-of-turn axis, deviation of acceleration along the end-of-turn axis, and deviation of the raw yaw rate were used to create features and utilize the Naïve Bayes classifier to classify drivers. The IMU sensor included in the smartphone was used to monitor and identify up to 12 drivers.
The technology that analyzes dangerous driving based on vehicle status information collects data through various sensors and analyzes driving behavior. However, this technology accurately analyzes driving behavior that moves mostly along the longitudinal direction of the road, but inaccurately for behavior that moves in the lateral direction.
On the other hand, vehicle operation information directly affected by the behavior of the driver is generally difficult to obtain from the vehicle. Han [3] extracted vehicle operation information from the on-board diagnostic system (OBD-II) in the vehicle and designed the system to send data to the driver's smartphone using bluetooth low energy (BLE) communication.
Martinelli [4] recognizes the driver's driving style by using vehicle status information and vehicle operation information. Vehicle status and operation information is obtained from the in-vehicle OBD-II system and includes 51 types of information, including fuel consumption, accelerator pedal position, steering angle, steering speed, and vehicle speed. Principal component analysis (PCA) was used to analyze the driver's disposition and to classify nine types of drivers.
As described above, in the case of the existing system using the vehicle status information and the operation information, not only is the driving behavior analysis not performed in real time, but it is also difficult to share data with other platforms due to the lack of complementary communication protocols.

System architecture
The proposed system detects basic dangerous driving behaviors such as sudden starting, sudden stopping, and radical turning in real time based on vehicle status information and operation information. It also analyzes additional driving information such as idling time, mileage, travel time and top speed. This information is then transmitted to the control server using LoRa, a low power long distance communication technology. Figure 1 shows the proposed system's architecture.
The proposed system consists of an information collection device, data server, and the driver's smartphone. The collection device collects vehicle state information and vehicle operation information through the OBD-II system of vehicle. Figure 2 shows a hardware block diagram of the proposed device. The information collecting device includes an MCU, a controller area network (CAN) communication unit for communicating with the OBD-II, a sensor unit for collecting status data of the vehicle, a Bluetooth communication unit for communicating with external components, and a LoRa communication unit.
The device transmits to the external component through the Bluetooth communication module and LoRa communication module according to the type of generated data. It transmits the information to the driver's smartphone through the Bluetooth communication unit and the information to the data server via the LoRa unit. It uses LoRaWAN protocol to send information to data server. The system requires a backend platform such as ThingPlug.
The data server receives aggressive and other driving information from the information collecting device. The server has a lightweight data exchange interface, such as JSON, which allows other applications to request and utilize the information received by the data server. The device can also transmit information directly to the target server being used by other applications.
The driver's smartphone receives driving information analyzed from the information collection device in real time using the Bluetooth interface of the smartphone. This allows the driver to be alerted to dangerous driving information in real time, and to expect immediate driving behavior correction through an alarm.

In-Vehicle data extraction algorithm
Two approaches can be used to obtain vehicle operation data from the in-vehicle CAN network. The first method is to directly communicate with internal electronic control units (ECUs) to acquire data, and the second is to monitor and analyze the communication between ECUs in the CAN bus contained in the OBD-II terminal of the vehicle. The first method is not suitable for practical applications as parts of the vehicle must be disassembled prior to connection. Many studies have already used the second approach successfully.
Representatively, Lim [5], acquires data through a multi-level filtering-based method of communicating data in the CAN bus. The first phase is the candidate collection phase, which collects all packets on the CAN bus for a specified period. The collected CAN packets are defined as the candidate data. During this period, packets are collected repeatedly for all states of the target vehicle. For example, in the gear position data, there are six states of parking gear, reverse gear, neutral gear, forward gear, second gear, and first gear based on a typical automatic transmission vehicle. That is, in this stage, every gear position is collected in all packets in the CAN bus for the collection period. The second phase is a data filtering phase, in which a packet indicating an operation state is selected from among the packets collected in the previous step. The data filtering phase consists of several filtering steps. In invariant filtering, duplicate packets among the collected packets in the same state are filtered. In distinct filtering, packets are compared for each state searching for packets having the same header information and different payload data. While a lot of operating information can be collected in the two steps above, some functions, such as turn indicators, need a further filter, such as a stripe filter. The turn indicator uses the flashing feature to turn on and search for packets with a 1:1 ratio of on and off.  When applied to a real vehicle, this method has two limitations. First, not all vehicles have the same status for the same function. For example, in the case of a turn signal, some vehicles have one state of off and one of on, and some other vehicles have three states of one of off, one of on-light on, and one of on-light off. This problem can be overcome by employing several types of filtering orders. Secondly, in recent vehicles, unified diagnostic services (UDS) are installed so that communication packets between different ECUs cannot be intercepted via the CAN network connected to the OBD-II. In the case of vehicles with UDS, the existing research technology cannot be used natively. UDS operates in a queryresponse format, in which the ECU-ID and Data-ID in the query message for each function to be collected must be known in advance. In addition, since the response format is different for each vehicle, a separate filtering algorithm is required for each installation type.
In this study, we design an algorithm with the structure depicted in Figure 3 and propose a method to extract the operation information of the vehicle in which the UDS is in use. The proposed algorithm consists of two stages: query searching and ID extraction.
The query searching step consists of searching for a valid ECU-ID and then finding a valid Data-ID for each ECU-ID. First, the ECU-ID is searched within the range of 700h to 7FFh using the ECU test message provided by the UDS standard. Sending a query with a valid ECU-ID returns a valid response, otherwise there is either no response or an error response. The next step works similarly. As the valid ECU-IDs are known from the previous step, we put all possible Data-IDs for each case into the query message for each ECU-ID and observe the response. Data IDs have a total of 65,536 cases between 0000h to FFFFh. After testing every case, the ECU-IDs and corresponding Data-IDs can be used to create a valid query message data set. Figure 4 illustrates the process of query searching. The ID extraction step has some similarities to previous studies' methods as shown in Figure 5.  The query message dataset collected in the query searching step is repeatedly transmitted. After that, using the algorithm derived in previous research, the response packet is collected and filtered after a status change of the object being observed.

Aggressive driving detection method
There are 16 data points of operational information analyzed by the system proposed in this paper and they are shown in Table 1. Risky driving behaviors such as rapid acceleration, rapid start, sudden deceleration, sudden stop and sudden turn are analyzed continuously. However, the information indicating the highest / lowest are only the highest / lowest peak values during the driving period between starting and stopping the vehicle. Therefore, the proposed data collection device should be able to detect when the vehicle is started and when it is turned off. The device should also supply time stamps of the events being recorded. Conversely, the device can detect the start-up is period is over when no more packets are sent to the CAN bus. So, when the device recognizes that it has turned on, it initializes the high and low information measurements and updates the high and low values until it is turned off.  Dangerous driving behavior was designated by referring to the criteria of 11 dangerous driving behaviors provided by Korea Highway Traffic Authority. Rapid acceleration is considered to occur when the vehicle accelerates 8 km/h per second at the speed of 6.0 km/h or more. Rapid departure is defined as accelerating more than 10 km/h per second starting from the speed below 5.0 km/h. Rapid deceleration is when the speed is decelerated by more than 14 km/h and the speed is more than 6.0 km/h. A sudden stop is defined as the case when the speed decreases by more than 14 km/h per second and becomes less than 5.0 km/h. In cases of rapid rotation, the speed must be over 30 km/h and the cumulative rotation angle is between 60~120 degree within 3 s.
To detect these conditions, acceleration data is obtained via the acceleration sensor of the collecting device, speed data information is obtained from the OBD-II inside the vehicle, and cumulative rotation angle data is calculated using the steering wheel data of the OBD-II. In general, since the steering wheel ranges from -540 degrees to 540 degrees, the cumulative rotation angle information for 3 s can be calculated using this.
In the case of mileage information, it is simply calculated using time and speed data inside the vehicle, and fuel consumption is calculated by using the technique described by Park [6] based on the mass air flow (MAF) data of the vehicle.

Experimental results
In this paper, we verify the operation of the proposed system and evaluate the communication performance and the performance of the in-vehicle information extraction algorithm by experiment. To this end, we designed and implemented a device for collecting information. The MCU of the device was the STM32F429 based on Cortex-M4 and equipped with an MCP2551 transceiver for CAN communication. SoluM's TLS01CS1 was installed as a LoRa communication module and a FB153BC was used as a Bluetooth communication module. An LIS331 was used for the acceleration sensor. Figure 6 is a picture of the prototype device. In addition, an Android application for driver notification and monitoring services was developed, and a data server and control application was designed and based on Ubuntu 16.04 as shown in Figure 7.
The system allowed real-time acquisition of dangerous driving indicators such as rapid acceleration, rapid start, sudden deceleration, sudden stop and sudden turn, as well as driving information such as the number of times the The experiment was conducted on two real roads and the driving course is shown in Figure 8. Each driving course consisted of a highway environment and a city road environment and was completed in about 10 minutes. Four male and four female drivers in their twenties and thirties with a year or more of driving experience participated. Data was collected during 10 repetitions of driving each course by each participant. Figure 9 is a confusion matrix for the success rate of detecting rapid acceleration, rapid start, rapid deceleration and sudden stop information. Events were detected at 1 s and 1.5 s intervals, respectively.
In the case of 1 s period, the recognition rate of the quick start event was 85%, then in the case of the 1.5 s detection period, it was confirmed that there were no misrecognition events. It was found that the detection success rate varies depending on the detection period and considering that the recorded events are affected by the acceleration change amount, it is necessary to adjust the recognition period according to the acceleration/deceleration performance of the vehicle. In the case of a rapid turn event, it was confirmed that there is no misrecognition because it uses directly measured steering information from the vehicle operation information.
As a result of the experiment, it is confirmed that there is an average error of 2.0%, which is small enough to be acceptable considering the error of the mileage value in the instrument panel is considered as a ground truth. The error rate was calculated by setting the measurements displayed on the dashboard of the vehicle as ground truth. It was also confirmed that no errors occurred in the detection and recording of the number of idling periods and time. The driving time was also calculated based on the start on / off time and confirmed that there was no significant error in its measurement either.
We evaluated the communication performance by examining the operating information which was sent to the control data server through LoRa communication. In the experiment, the information packet was transmitted every 10 s while driving on the course of Figure 8.  Table 2. We confirmed that the Mono antenna performed best in the highway environment. However, we found that coil antennas have the lowest PER on city roads.
In order to evaluate the performance of the in-vehicle extraction algorithm proposed in this paper, a total of 14 vehicles were tested. Seven parameters of the internal information were examined including vehicle speed, engine RPM, steering angle, accelerator pedal depth, brake pedal depth, gear position and integration distance.
The experimental results are shown in Table 3. The section labelled UDS in Table 3 is data that could be obtained by the extraction algorithm proposed in this paper, and not by the existing extraction algorithms. For Hyundai, Kia and BMW, it is often found that information is needed through UDS on the vehicles manufactured after 2017. It was observed that the steering angle and integration distance information of some models were difficult to obtain. For this reason, the query message data set could not be saved for these measurements due to insufficient memory of the embedded device. Since the algorithm proposed in this paper conducts exhaustive search, a limitation exists in that all messages cannot be saved when the number of valid messages which must be retained are too large. It is also confirmed that the ECU-ID and Data-ID pair deduced through this extraction algorithm are not specified for the integration distance information of Renault SM6 vehicle. Finally, it is confirmed that an extraction time between 6 to 16 hours is required depending on the vehicle make/model and the information to be acquired when using the proposed algorithm.

Conclusion
In this paper, we designed and implemented a system that can extract driving information including dangerous driving behaviors in real time and transmit it to a data server through LoRa communication in real time. We also propose an internal information extraction algorithm that supports the UDS protocol to obtain the vehicle's interior information.
The performance of the proposed system was evaluated through experiments on real roads. It showed that the driving information can be detected in real time, and the information can be transmitted to the data server through LoRa communication. It was confirmed that the recognition performance of some operation information differs depending on the measurement cycle duration.
We verified the proposed algorithm for extracting the in-vehicle information through various methods and discovered difficulties in the extraction due to issues encountered such as insufficient memory of the prototype device for some of the tested vehicles. We also identified the limitations of the extended time required for extraction. In the future, we plan to reduce the extraction time and the size of the query message set.