CAD3: Edge-facilitated Real-time Collaborative Abnormal Driving Distributed Detection

Abstract

Speeding, slowing down, and sudden acceleration are the leading causes of fatal accidents on highways. Anomalous driving behavior detection can improve road safety by informing drivers who are in the vicinity of dangerous vehicles. However, detecting abnormal driving behavior at the city-scale in a centralized fashion results in considerable network and computation load, that would significantly restrict the scalability of the system. In this paper, we propose CAD3, a distributed collaborative system for road-aware and driver-aware anomaly driving detection. CAD3 considers a decentralized deployment of edge computation nodes on the roadside and combines collaborative and context-aware computation with low-latency communication to detect and inform nearby drivers of unsafe behaviors of other vehicles in real-time. Adjacent edge nodes collaborate to improve the detection of abnormal driving behavior at the city-scale. We evaluate CAD3 with a physical testbed implementation. We emulate realistic driving scenarios from a real driving data set of 3,000 vehicles, 214,000 trips, and 18 million trajectories of private cars in Shenzhen, China. At the microscopic (road) level, CAD3 significantly improves the accuracy of detection and lowers the number of potential accidents caused by false negatives up to four times and 24 times as compared to distributed standalone and centralized models, respectively. CAD3 can scale up to 256 vehicles connected to a single node while keeping the end-to-end latency under 50 ms and a required bandwidth below 5 mbps. At the mesoscopic (driver-trip) level, CAD3 performs stable and accurate detection over time, owing to local RSU interaction. With a dense deployment of edge nodes, CAD3 can scale up to the size of Shenzhen, a megalopolis of 12 million inhabitant with over 2 million concurrent vehicles at peak hours.

Street Smart in 5G: Vehicular Applications, Communication, and Computing

“…A separate data fusion module facilitates fusing and aggregating the topics' data for richer features and better context determination. Spark Streaming then either consumes data from specific Kafka topics or retrieves data from HDFS, [94], Kafka [11], [95], or Flume [96]), micro-batch streaming then ML-assisted processing (using Flink [97], [98] or Spark Streaming and MLLib [10], [99], [100]) and splits the data into micro-batches to feed into Spark MLlib which applies ML algorithms. Apache Flink could replace spark to achieve a very similar setup.…”

“…The platform enables pipelined fault-tolerant dataflows and supports many classes of data processing applications, including realtime analytics, continuous data pipelines, historic data processing (batch), and iterative algorithms (machine learning, graph analysis). To detect unsafe driving activities, Alhilal et al [10] integrates Apache Kafka and Apache Spark. Specifically, Kafka collects and aggregates the vehicle data, while Spark streams and divides the data into micro-batches, then processes the batches using Spark MLlib.…”

“…Moreover, traffic flows change due to abnormal traffic events such as road incidents. Therefore, many applications on the local scale require contextawareness as well as situational-awareness to make accurate decisions [10], [92]. Additionally, the vehicles must maintain continuous, uninterrupted, and highly available communication between each other and with the RSUs.…”

“…The data streaming module ingests and aggregates the traffic data streams then fuses both the aggregated data and potentially stored data from the data management system. Afterwards, the streaming module divides the fused data flow (continuous in nature) into (micro)batches for processing using the data analysis module [10], [11], [130].…”

“…Additionally, as previously stated, the connection may be intermittent, resulting in massive data bursts that need to be processed in real-time. Analyzing this data and promptly extracting meaningful and useful information requires the consideration of specific big data architectures in the deployment of connected vehicular systems [10], [11].…”