Guidelines for OBD Reader Android Application Development

OBD adapter is an electronic device that allows a computer to access the vehicle network through its ECU (Engine Control Unit). OBD2 adapter can be plugged into the OBD2 ports (Data Link Connector (DLC)) in a vehicle. Data coming from the ECU can be retrieved from an android application via Bluetooth connection. OBD2 provides real time data.

Data flows both ways through OBD2 to and from the ECU. This will be the flow of data

1.  Mobile application sends request to the OBD adapter via Bluetooth interface (AT commands).
2. OBD2 adapter receives the request.
3. OBD2 retransmits the request to the ECU on one of the OBD protocols
4. ECU responds back with the data to OBD2.
5. OBD2 sends data to the mobile application.

A protocol is used for the communication between OBD device and android application. It is text based polling type protocol. That means you should send commands as requests in order to get a response. 

OBDSim

Since it is not possible always to test OBD2 related applications in a real environment with a vehicle there are existing application which has the capability to simulate a vehicle with an OBD device plugged in.

OBDSim is one such simulator which we have used to test our mobile application. This is a cross platform and works on Windows/ Linux software platforms. Similar to ELM327 OBD2 adapter this also works on AT commands which are used to configure an ELM327.

Installing OBDSim

You can download it from this link http://icculus.org/obdgpslogger/.

Useful links to set up OBDSim

1. http://stackoverflow.com/questions/13164150/obd2-elm327-bluetooth-simulator?lq=1
2.  http://stackoverflow.com/questions/21957505/connect-obdsim-to-torque-on-windows-through-bluetooth
3. http://stackoverflow.com/questions/25720469/connect-obdsim-to-torqueandroid-app-ubuntu/25763606#25763606

After installing and running the OBDSim we can manually change the parameters and test our application.

Developing Android Application

Application should be capable of performing following functionalities.

• Connect to OBD device through its Bluetooth interface.

• Initialize OBD adapter with AT commands.

o   AT SP 0 - This is to set the protocol to “AUTO”. That means we want the interface to automatically detect the protocol when we send the first OBD request. If it is successful reply will be “OK”.

o   AT DP - To verify the protocol (Display Protocol). Reply – “AUTO

•      Continuously retrieve data from OBD adapter.

We have to use OBD-II Parameter IDs (On-Board Diagnostics Parameter IDs - PIDs) in order to communicate with the vehicle. Those individual PIDs provide some specific information on vehicular data. 

OBD-II PIDs (On-Board Diagnostics Parameter IDs) are codes used to request data from a vehicle. There is a standard set of PIDs which is defined by SAE standard J/1979. Other than that, manufacturers define their own PIDs.

Process of communication through PIDs.

1.  Mobile application sends PID s as requests to the OBD2 adapter.

2. OBD2 device sends it to the vehicle’s controller area network (CAN).

3.  A device on the bus recognizes the PID as one it is responsible for, and reports the  value for that PID to the bus.
4. OBD2 reads the response and send it back to the mobile application.

 Example PID s that are sent to get speed and RPM.

           o   010C – Get RPM. Example reply – “41 0C 0F A0”. The reply contains two bytes that identify it as a response to Mode 1, PID 0C request (41 0C), and two more bytes with the encoded RPM value (1/4 RPM per bit). To get the actual RPM value, convert the hex number to decimal, and divide it by four: 

                                                     0x0FA = 4000

                                                     4000/4 = 1000 rpm

o   010D – Get vehicle speed.  Reply – 41 0D FF. To get the speed have to convert this to decimal.

Crowdsourced traffic data analysis and visualizing using WSO2 CEP.

Introduction

Aim was to develop a mobile application and a website to get reliable traffic data in certain areas. GPS data received from smart phones of users was analyzed via CEP. When the users log into the android application their GPS data was sent to the CEP. From the data received, it was possible identify the location and moving speeds of users. Analyzing the traffic condition was done inside CEP. After analyzing, crowd sourced data about traffic is displayed on a map. 

Usage of geo-fencing and level of service to calculate traffic

Geo fencing is a feature that can be used in a software program to define the geometrical boundaries. In our project this technology was used to segment the road. Geo-fencing custom extension in WSO2 CEP is used to define the boundaries and filter vehicular data. When CEP receives an event, its coordinates are checked against the defined boundaries to check whether it is inside or outside, using OSGeo Geo Tools library [1].

We used the method Average Travel Speed (ATS) to calculate traffic level of service.

ATS = Distance / average time of vehicles

One execution plan includes all the required processes to calculate the traffic status of a particular road segment. 

User’s imei number, longitude, latitude values were passed in to the execution plan from an event stream.

In the execution plan two polygons in one junction were defined using longitude and latitude coordinates of the road segments. When CEP receives an event check whether it was within the range of defined polygons. If they were within those polygons events were sent to two different streams based on the polygon which they belong to.

Siddhi Query

from nospeedstream[geo:iswithin(longitude,latitude,"{'type':'Polygon','coordinates':[[[79.84941602,6.91021645],[79.85038161,6.91049338],[79.85070348,6.90979042],[79.84948039,6.90930048],[79.84941602,6.91021645]]]}")==true]

select imei , longitude,latitude,timemili

insert into filteredPoly1;

Then the entering time stamps of each individual vehicle for first polygon and the second polygon were recorded separately. And those timestamps and imei number of vehicles were passed to another stream.

from filteredPoly1#window.unique(imei) as p1 join filteredPoly2#window.unique(imei) as p2

on p1.imei == p2.imei

select p1.imei as imei, p1.timemili as timemili1,p2.timemili as timemili2

insert into joinedpolydata;

from joinedpolydata#window.firstUnique(imei) as p1

select * insert into uniquejoinedpolydata;

After that, time difference of each vehicle was calculated. If it becomes negative that indicates the vehicle is travelling to the opposite direction. From that we can separate the vehicles according to their travelling directions. Vehicles having positive time differences were sent to the ‘positivetimeDiffStream’ and negative ones were sent to the ‘negativetimeDiffStream’.

from uniquejoinedpolydata

select imei, (timemili2-timemili1) as timediffmili

insert into timeDiffStream;

from timeDiffStream[timediffmili>0]

select imei,timediffmili as postimediffmili

insert into positivetimeDiffStream;

from timeDiffStream[timediffmili<0]

select imei,(-1*timediffmili) as negtimediffmili

insert into negativetimeDiffStream;

Then the average time difference of all the vehicles belonging to that road segment within a particular time period was calculated for both directions.

from positivetimeDiffStream#window.time(30 sec)

select "Kolpity" as junc_id,avg(postimediffmili) as free_flow_speed_d1

insert into avgtimediffmilistream;

from negativetimeDiffStream#window.time(30 sec)

select "Kolpity" as junc_id,avg(negtimediffmili) as free_flow_speed_D2

insert into avgtimediffmilistreamneg;

Then the average vehicle speeds of each direction were calculated and the distance of road segment was divided by it to calculate the average speed of each direction.

from avgtimediffmilistream

select junc_id, ((1000/free_flow_speed_d1)*5/18) as free_flow_speed_d1

insert into avgspeedpositive;

from avgtimediffmilistreamneg

select junc_id, ((1000/free_flow_speed_D2)*5/18) as free_flow_speed_D2

insert into avgspeednegative;

This average speed data was then sent to a mysql database through a mysql output adapter in CEP [2].

From this average speed, we can define the traffic level of each direction in application level.

API

A REST API was introduced for outside apps to can call and get data from the system. The API was written using WSO2 Jaggery. It is possible to receive the following metrics through the REST API.

Get all traffic data

Sample request:

GET /apis/traffic

Sample response

Get traffic for specific junction

Sample request:

GET /apis/traffic?junc_id=kolpity

                   

junc_id : We can get traffic status in a particular junction. 

Sample Response

All traffic(only traffic info)

Sample request:

GET/apis/traffic?trafficonly=true

Sample response:

Traffic for specific junction (only traffic info)

Sample request:

GET/apis/traffic?junc_id=kolpity&trafficonly=true

Sample response

Finally, traffic condition will be visualized on a google map as in the picture shown below. Red marks are for visualizing high traffic areas and green marks are used to visualize low traffic areas.