# Traffic Congestion Detection System through Connected Vehicles and Big Data
## 3 Proposal Architecture
### Big Data Cluster  
Cars forming part of the network of connected vehicles generate a continuous stream of information that is sent to the Cluster which receives it by means of an API resident on an application server, responsible for receiving and interpreting data in order to detect traffic congestion events. This section details the features of the Cluster and defines criteria for interpreting traffic congestion events. Traffic congestion is considered any event which combines low vehicle speeds and long queues formed by this slow moving cars. The system maintains a registry with the threshold speed and length  
Figure 2: General architecture of the traffic detection system. of acceptable cues for each road in the scenario to enhance the sensibility of the traffic congestion alert generation. The cluster is composed of 10 identical computers and an application server. Each one of the computers possesses 16 GB DDR3L RAM, 500 GB HDD, Core i7 processor at 2.2 GHz, and a Gigabit Ethernet interface. The 10 computers are connected in a star topology to a 10/100/1000 Base-T 24-port Switch. Each computer runs a 64-bit Ubuntu 14.04.1 LTS operating system, to which Java 1.7.0_75 and Cassandra 2.0.2 were installed. The application server has 16 GB DDR3 RAM, 1 Tb HDD, Intel Xeon E5 processor at 2.4 GHz and a Gigabit Ethernet interface, running a Windows Server 2008 operative system, to which SQL Server 2008 R2, JDK--JRE 1.8 and Tomcat 8 were installed. The cluster is formed by a node that serves as Master and 9 nodes that act as slaves. All nodes are configured in a communication ring to selectively share their public keys, allowing each node to connect via SSH with its two neighboring nodes without a password. The application server communicates only with the master node using SSH, as shown in Figure 3.  
For this application, we decided to use a Kappa architecture because the system does not require the speed layer of the lambda architecture to process the real-time data. The badge collects the incoming stream in a specified amount of time to estimate traffic congestion events. Figure 4 shows the used architecture and the main data flow. Figure 4: Big data architecture. Figure 3: Diagram of the big data cluster network. Cassandra is used to support a high flow of inserts and queries, using its distributed architecture. Figure 5 provides the data model implemented in Cassandra to store and view vehicle information:  
The OnRoad_Vehicle_Data model consists of an integrated primary key, which is composed by cluster_id to identify each of the monitoring points, timestamp id to provide the date and time when the vehicular information was sent and a vehicle id to provide a unique identifier for each car in the VANET. The data in each record includes latitude vehicle, longitude vehicle, speed vehicle, temperature vehicle, as well as a package counter. All of this information is sent at one-second intervals from the vehicles in the VANET to the application server which forwards all the information to the Cluster. SQL Server is used to store a traffic event log from the information contained in Cassandra, as well as a catalog of coverage points. Figure 6 shows how the model is implemented:  
The OnRoad_Cluster_Data model is a catalog containing the following fields: road_id to provide the street on which the vehicles are traveling; cluster_id to define the coverage points; road_sequence to identify a number of consecutive coverage points on the street, applicable in settings where the streets are linear or curved; latitude_point and longitude_point to determine the decimal format GPS coordinates of the center point of the coverage; diameter_point to determine the coverage diameter in meters from the point of coverage and average_speed to provide the average speed in km/h for cars with the diameter of the coverage point.