Functional Specification

Functional Specification

OBD Reader App

Contents

Functional Specification

Introduction

Purpose

Scope

Definitions, Acronyms, and Abbreviations

Project Description

Operating Environment

Design and Implementation Constraints

Assumptions

User Documentation

Introduction Materials

Detailed Requirements

Administration Interface.

Communication Interfaces

System Functionality

Usability

Ease of Use

Responsiveness

Vision Document

Purpose

Scope

Definitions, Acronyms, and Abbreviations

Positioning Business Opportunity

Functional Specification

Introduction

The number of vehicles registered in Ireland far exceeds that of the population. That number is rapidly growing, up 30% from this time last year. While car use for many is a necessity and is thought of as nothing more but a means of travel, for many their car is a hobby. Like many enthusiasts, “motorheads” enjoy tweaking the inner workings of their cars to get the maximum output from their vehicles. The On-Board Diagnostic Reader is a solution to those users who want a way to accurately benchmark their cars, without the high cost of a professional workshop. However, the usage of this application extends past the enthusiast market, the general user can also find use in the applications diagnostic features. These features allow the user to diagnose errors in the system via trouble codes read out by the cars on board computer, allowing for a mechanic to address the issue faster, therefore cutting down on hours worked.

Purpose

The purpose of this document is to provide a detailed overview of the functionalities of the application. This will include the applications features, dependencies and scope. It is important to outline these prior to development, especially scope.

Scope

The On-Board Diagnostic Reader aims to provide an easy way of properly benchmarking cars. This requires a number of different sections of the system which we will need to identify and provide scope for individually if we are to get an accurate overview of the system.

Android Application

The OBD Reader will include an android application for the user to use in conjunction with an OBD Bluetooth adapter which will be provided. The android application will need to provide functionality for receiving data from the vehicle, and uploading data to the server. The user should also be able to access data about their car on the app.

Web Application

The web application will need to provide the user with the ability to register, login and see more detailed information about their vehicles. The web application will need to provide support for a database where the data regarding the user and their vehicles is stored.

Definitions, Acronyms, and Abbreviations

Project Description
This section will provide a description of the application in general terms.

The diagram shows the mobile applications communication with the server and the dependencies on API's. The mobile app will need to use Bluetooth and GPS from the native Android libraries. In order to use the GPS libraries the device needs to have access to the Google Play Store API's. Interfacing with the server will be done via HTML requests, using JSON as the payload.

Operating Environment

The application will operate on devices running Android Kit Kat 4.4.4. and above installed Android versions. The reason this has been chosen is to provide access to up to date API's on Android and because of Kit Kat's large install base.

Design and Implementation Constraints
The application relies heavily on the device having a steady internet connection throughout the user's journey. The application will need to interact with a server while the vehicle is moving and network connectivity may become an issue.

Also something to consider is the Bluetooth connectivity with the device, because Android is deployed on all kinds of devices, some Bluetooth devices may struggle to maintain a quality connection with the adapter and cause the app to lose connection, resulting in data loss. Some devices that run Android do not have Bluetooth connectivity at all and therefore cannot be supported by this application in its current implementation, support for a usb connection is possible, but is out of scope. It is important in a situation where the user does not have bluetooth enabled, that the application correctly responds and informs the user of the problem.

Because the driver must not be distracted whilst driving, I will aim to keep the UI of the application simple, so it will not need to be interacted with whilst in use. A UI that is complex and difficult to use may result in the driver trying to use the mobile whilst driving and causing an accident.

Assumptions
It is assumed that the user understands that this application can only work on vehicles that support the OBDII standard. If the vehicle does not have an OBDII port then the application will be unable to receive signals from the vehicle and cannot function correctly. This is especially important because not all vehicles support the OBDII standard.

It is also assumed that the user has access to an OBDII Bluetooth adapter for use with the application. Without this the application will be unable to interface with the vehicle.

Thirdly, it is assumed that the device has Google Play Services installed. This is important as the GPS co-ordinates require Google Play Services to be installed. Without this dependency met the application will be unable to receive the devices current location.

Lastly, it is assumed that the Android device has enough system resources to allocate to the application for it to run in an acceptable manner, if the application is unable to receive enough resources it may behave erratically and function incorrectly

User Documentation

Development Documentation

The development documentation will adhere to the standards set out by the Institute of Technology Carlow.

Introduction Materials
The introduction materials for the expected users will include:

- A short video detailing the initial setup and first use of the product. This will include, installing the Bluetooth adapter, logging a journey, and analysing the results.

-A readme hosted on the GitHub repository detailing installation instructions.

Detailed Requirements
User Interfaces

The user interface of the mobile application will have to be kept relatively simple. The theme will be “Carbon” in fitting with the usage of the application being centred around modified vehicles. This will include a stylized background and Holo Black theme for the UI elements. The user interaction with the application will be kept minimal and only when necessary. It is important that users be able to use the application immediately and with little to no training involved. Navigation will be done via buttons onscreen and navigating to prior screens will be handled via the hardware back button (onscreen or physical, device dependant) as is the standard for Android applications.

The original plan for the User Interface was to meet the design standards set out in Google's Material Design specifications, unfortunately this will not be possible due to time limitations and the majority of material design API's residing on Android Lollipop (5.0) and therefore testing on a physical device would be impractical due to Android Lollipop's limited availability.

Administration Interface.
The applications administration interface will be handles via PythonAnywhere's administration interface and will not need to be written in conjunction with the application. This interface allows an Admin to view all tables and make modification to the data if necessary, view the applications access logs and any errors that were reported from the application.

Communication Interfaces

The mobile application will need to be able to communicate directly with the web application due to the way PythonAnywhere manages it's MySQL databases. This will be facilitated though HTML requests and responses from the server. Using a JSON payload the mobile application will send the required data to the server for it to process and enter into the MySQL databases correctly. Once the user begins logging data using the mobile application, this communication will begin to happen automatically until the user stops the logging process.

The application will also have to communicate to the Google Play Servers for the purpose of gathering location data. This will also be automatic when the user begins logging and will only update when the user changes location.

System Functionality

User Profiles
In order for the application to serve each user correctly we will need to keep track of each individual user. This will require them to register when they first use the system and log in for each subsequent use of the application. A user may have multiple vehicles tied to their account and can log journeys with each vehicle.

Car Registration

The application must provide a way to register a user’s car within the system. Each car must be uniquely identified and it must be possible to identify which car created what journey etc.

Log Journey
The application will need to be able to create a Journey. A Journey is identified as a starting point of the logging process and will end when the logging process has finished. During a Journey, Timestamps will be created which contain the data readouts from the Bluetooth adapter inside the car, along with other data taken from the device, such as the GPS co-ordinates etc. The application will have to correctly handle the creation of these objects and the storage of them in the server. This will involve communication between the Android device and the server.

View Journey/Timestamps

The web application will have to present the user with the option to review their own Journeys and Timestamps created by them. This will need to be formatted and shown to the user so they may extract the necessary data from the logging.

Data Analytics

The application will need to provide a more advanced look at the data gathered from the user. For the purposes of this project I will be working with Fuel Efficiency, this means that the application must be able to calculate the fuel efficiency over time for a given vehicle and output the result to the user. This output must be of meaningful use to the user, will need to take into account different locations causing higher fuel usage, speed etc. This will be done through the web application, where the user will be presented with a graph of the data and . The data will also have to be stored in such a way that makes it easy for third parties to use the data for their own data analytics services. This will be done by gathering any relevant data and having it stored in a MySQL database.

Usability

Look and Feel
The application will need to be consistent in its design across screens. It is important that this remain consistent for the user experience to be enjoyable. Implementing Google’s Material Design may help to provide an enjoyable user experience.

Feedback
It is important for the user that the application provide appropriate feedback. The application will provide a Toast anytime an upload is successful and will create an alert message when an error has occurred. Without proper feedback users can be unsure if the application is correctly responding to their inputs.

Ease of Use

The application will need to have a simple layout, if the application is too complicated to use first time, we will lose users who feel intimidated and out of their depth with the application. Screens should be quick to navigate for power users but at the same time provide enough detail that new users understand what it is they are doing.

Responsiveness
The application must not have a delay when the user attempts to click something on the screen, “lag” in this case is off putting and negatively effects user experience.

Vision Document

Purpose

The purpose of this document is to analyse and define high level features of the On-Board Diagnostic Reader. This document will focus on the business needs of the product as well as the target users. It will also outline why the product needs to exist and how the product is the correct solution to the problems outlined.

Scope
This Vision Document concerns the development of the On-Board Diagnostic Reader. This application will consist on an Android application that interfaces with both a Bluetooth adapter and also a webserver. The webserver will also host a web application that can be used by the client to access relevant data regarding their usage of the application. This will include things like fuel efficiency and GPS co-ordinates of the user’s vehicle.

Definitions, Acronyms, and Abbreviations

PositioningBusiness Opportunity

There are currently few opportunities for car enthusiasts to benchmark their cars in a safe and secure manner and that does not put anyone involved at risk. This application aims to give car enthusiasts a way gathering relevant data about their vehicle to which they can compare against others. This type of system is popular in the enthusiast computer hardware market with tools like 3dMark being quite popular amongst enthusiasts. While the demographic may be different, the principles remain the same, a platform where experienced users can demonstrate their abilities will encourage users to compete. It is with this in mind that I aim to provide these functionalities to the users.

Also, this data is relevant to more than just enthusiast users, the data gathered whilst performing these benchmarks can be relevant for third parties to assist in providing their own services to users.

This application can also be used to read accurate trouble codes from the engine, which in turn allows for easier home diagnoses.

Problem Statement

There are a lot of difficulties in properly gathering data from a vehicle's on board diagnostic system. Vague check engine lights and various monitors can leave the user too frustrated to attempt to find a solution to the problem themselves. A lack of feedback like this can often lead to a costly journey to the mechanics where the user may not even get the correct diagnosis to the issue. The solution to this is an application that allows users to diagnose their vehicle's issues without the use of a mechanic, helping them to be better informed when they do need to see a mechanic.

Another persistent problem faced by motorists is lack of knowledge about the how their driving habits affect their fuel efficiency, this can be solved by having proper logging available to them so they can make changes to increase their fuel efficiency by improving their driving habits. E.G not relying so heavily on breaking to slow down in traffic etc.

1