# A Crowdsensing Platform for Monitoring of Vehicular Emissions: A Smart City Perspective
## 3 Platform Architecture
### Data Collection  
A mobile application installed on a smartphone is used to retrieve the required data. Due to the limitations of the OBD-II scanners, only Versions 2 and 3 of the Bluetooth protocol are supported. For the development of this project, a smartphone with the Android operating system was used. As the communication between the device and the vehicle (ELM327) will be performed via Bluetooth, it is necessary to maintain these elements at a maximum distance between 10 and 15 m in order to avoid any communication failure.  
The application for data retrieving was developed with the intention of obtaining as much information as possible from the vehicles, particularly data from the OBD Operation Mode 1. Table 2 presents all operation modes of OBD, as a reference.  
Figure 1: Architecture overview.  
An optional implemented feature requires that the smartphone be connected to the Internet so that the data can be sent wirelessly to a remote server, contributing to a database that will store the data collected from each vehicle. For the version considered in this article, the collected data were stored locally on the device, leaving this optional feature for future analyses.  
In the diagram shown in Figure 2, the communication processes between the smartphone application and the monitored vehicle are demonstrated.  
The general steps of this communication process are defined as follows:  
1. The application sends a connection request to the ELM327 adapter via Bluetooth. With the communication established, the application can send commands to the OBD-II.
2. The application requests some data from the sensors, for example the Mass Air Flow rate (MAF) and Manifold Air Pressure (MAP), to obtain the amount of air entering the engine.  
\begin{table}
\begin{tabular}{c l} \hline \hline
**Mode** & **Description** \\ \hline
01 & Return the real-time ECU data. \\
02 & Request the ECU data corresponding to the last failure. \\
03 & Display the error codes stored in the vehicle. \\
04 & Clear the stored error codes. \\
05 & Return the test results of O\({}_{2}\) sensors present on the vehicle. \\
06 & Return the test results related to non-continuous monitoring. \\
07 & Return test results related to continuous monitoring. \\
08 & Require the control of the on-board systems. \\
09 & Get vehicle information. \\
10 & Displays the error codes with permanent status. \\ \hline \hline \end{tabular}
\end{table}
Table 2: Operation modes supported by OBD-II.  
Figure 2: System communication flow.  
The application receives the response from the OBD-II, and the platform calculates the CO2 emitted by the vehicle. The details of the methods used for the calculation will be shown in Section 4.1.  
In order to obtain the value of CO2 from the methods presented herein, the monitored vehicle must implement the OBD-II commands 0110 (MAF), 010B (MAP), 010F (IAT), and 010C (RPM).  
Figure 3 presents a \"screenshot\" of the operation of the developed application. This application, although still under development, is already at a functional level, and it can show all the readings returned by the OBD-II adapter. In this stage, it can be seen, for example, the fuel type that is being used by the vehicle, as well as its current level, the revolutions per minute, and many other sensor readings. For this article, the relevant values are the Mass Air Flow rate (MAF), Manifold Air Pressure (MAP), and air intake temperature.  
It is worth mentioning that some OBD commands, even though being part of the set of standard PIDs, may not be supported by some vehicles. This may be caused by manufacturers using custom codes instead of the default ones.