A

Project Report

On

VEHICLE TRACKING

Submitted in partial fulfillment for the award of degree of

Bachelor of Technology

By
ASHISH SHARMA
15EJCCS705

YASH AGARWAL
15EJCCS759

HIMANG SINGH SOLANKI

15EJCCS717

AKASH KHANDELWAL
15EJCCS703

VIVEK PANDEY
15EJCCS7

Department Of Computer Science & Engineering

Jaipur Engineering College & Research Centre
Jaipur, Rajasthan
2018-19
 A

Project Report

On

VEHICLE TRACKING

Submitted in partial fulfillment for the award of degree of

Bachelor of Technology

in

Computer Science & Engineering

Submitted By Guide Supervisor

AKASH Mr. Ankur Raj Mr. RajanJha

KHANDELWAL
15EJCCS703
 CANDIDATE’S DECLARATION

We hereby declare that the work presented in this project entitled “VEHICLE
TRACKING” for subject “Project-I” in the partial fulfillment of the award of the Degree
of Bachelor of Technology in Computer Science & Engineering at Jaipur Engineering
College and Research Centre, Jaipur is an authentic work of my own.
We have not submitted the matter embodied in this project work anywhere for the award
of any degree or diploma.

Place - JECRC Foundation, Jaipur

Date – 12.10.2018
AKASH KHANDELWAL
15EJCCS703
 BONAFIDE CERTIFICATE

This is to certify that the project entitled "Vehicle Tracking"is the bonafide work carried
out by Ashish Sharma, Himang Singh Solanki, YashAgarwal, AkashKhandelwal,
VivekPandeystudents of B.Techin Computer Science &Engineering at Jaipur
Engineering College and Research Centre, during the year 2018-19, for subject “Project-
I” in partial fulfillment of the requirements for the award of the Degree of Bachelor of
Technology in Computer Science & Engineering and that the project has not formed the
basis for the award previously of any degree, diploma, fellowship or any other similar
title.

……………………… …………………………
Mr. Ankur Raj Mr. RajanJha
(Project Guide) (Supervisor)

Place: JECRC Foundation, Jaipur

Date:
 ACKNOWLEDGEMENT

We wish to express our sincere gratitude to our respected Supervisor Mr. RajanJhafor having
given us the opportunity to undertake our project.

We also wish to express our sincere thanks to respected Project Guide Mr. Ankur Raj for his
encouragement, guidance, and support that he extends towards our project work for its successful
completion.

AKASH KHANDELWAL

(15EJCCS703)
 ABSTRACT

Fleet management is the management of:

 Commercial motor vehicles such as cars, vans, trucks, specialist vehicles (such as
mobile construction machinery), and trailers
 Private vehicles used for work purposes (the 'grey fleet'[1])
 Aviation machinery such as aircraft (planes and helicopters)
 Ships
 Rail cars

.
Fleet (vehicle) management can include a range of functions, such as vehicle financing,
vehicle maintenance, vehicle telematics (tracking and diagnostics), driver management,
speed management, fuel management and health and safety management. Fleet
Management is a function which allows companies which rely on transportation in
business to remove or minimize the risks associated with vehicle investment,
improving efficiency, productivity and reducing their overall transportation and staff
costs, providing 100% compliance with government legislation (duty of care) and many
more. These functions can be dealt with by either an in-house fleet-management
department or an outsourced fleet-management provider. According to market research
from the independent analyst firm Berg Insight, the number of fleet management units
deployed in commercial fleets in Europewill grow from 3.05 million units at the end of
2012 to 6.40 million in 2017.[2] Even though the overall penetration level is just a few
percent, some segments such as road transport will attain adoption rates above 31
percent.

.
 TABLE OF CONTENTS

Candidates Declaration------------------------------------------------------------------------------------1
Bonafide Certificate----------------------------------------------------------------------------------------2
Acknowledgement ------------------------------------------------------------------------------------------3
Abstract-------------------------------------------------------------------------------------------------------4
1. INTRODUCTION---------------------------------------------------------------------------------------10
1.1 Purpose -----------------------------------------------------------------------------------------------10
1.2 Project Scope-----------------------------------------------------------------------------------------10
1.3 Document Convention ------------------------------------------------------------------------------11
2. REQUIREMENT ANALYSIS-----------------------------------------------------------------------12
2.1 Hardware Requirement------------------------------------------------------------------------------12
2.2 Software Requirement ------------------------------------------------------------------------------12
2.3 Functional Requirement-----------------------------------------------------------------------------13
2.4 Non-Functional Requirement-----------------------------------------------------------------------14
3. SYSTEM DESIGN--------------------------------------------------------------------------------------16
3.1 Use Case Diagram-----------------------------------------------------------------------------------16
3.2 Firebase Database Design-------- -----------------------------------------------------------------17
3.3 Activity Diagram------------------------------------------------------------------------------------18
3.4 Deployment Diagram for Android---------------------------------------------------------------19
3.5 Angular & Ionic Application Architecture------------------------------------------------------20
4. ANGULAR ARCHITECTURE-----------------------------------------------------------------------21
5. IONIC STRUCTURE-----------------------------------------------------------------------------------25
6. SCREEN SHOTS---------------------------------------------------------------------------------------27
7. TESTING ------------------------------------------------------------------------------------------------33
8. LIMITATIONS OF PROJECT----------------------------------------------------------------------39
9. FUTURE SCOPE OF PROJECT-------------------------------------------------------------------40
10. REFERENCES----------------------------------------------------------------------------------------41
 1. INTRODUCTION

1.1. Purpose

The purpose of Fleet Management in a business is to ensure the work vehicles of a

business are operating smoothly, are constantly seeking ways to improve performance,
are able to keep operation costs at a minimum, and maintain compliance with government
regulations.
Fleet management software in a business, we need to point out the growing awareness of
how Fleet Management Systems optimize processes and improve efficiency of adopters,
the implementation of strict government regulations for transportation companies
regarding safety measures and the growing popularity of mobile devices are expected to
drive the market at an amazing CAGR of 20% from 2017 to 2025.

1.2. Project Scope

While this suggests an overall positive picture for the future of Fleet Management
providers, current realities about rising operational costs due to increasing expenditures
on maintenance, rising demand for utility vehicles, and the escalation of keeping up with
compliance costs cast clouds of doubts over the horizon. Indeed, the fleet management
software market has been seeing meager margins for some time, resulting in providers
looking at streamlining operations to bring them back to regimes of comfortable
profitability in the long run.
As with many industry sectors, such developments may be seen as the birth pangs of
businesses and societies marching inexorably to the era of internet of things, when driver
and vehicle communicate in more effective ways, and when vehicle-to-vehicle and
vehicle-to-infrastructure connectivity is but a foregone conclusion. That kind of future
suggests a mind-boggling deluge of new data that would demand a new approach,
perhaps from predictive analytics of today to the more widespread application of
prescriptive analytics on fleet management of tomorrow.
1. REQUIREMENT ANALYSIS

1.1. Hardware Requirement

Following computer hardware and network requirements will be needed to complete
development activities at minimum:

T y p e S p e e d C P U s R A M D i s k

P e n t i u m 2 . 4 G H z S i n g l e 4 G B 4 G B

i 3 / i 5 / i 7 2.5 GHz and above S i n g l e 4 GB and above 4 G B

M a c O S 2.5 GHz and above S i n g l e 8 G B 1 5 0 G B

1.2. Software Requirement

In addition to the application and any other customer specified software, the following list of
software should be considered a minimum:

M i s c e l l a n e o u s V e r s i o n

IDE - Visual Studio Code 1 . 8 . 1

Node Package Manager (npm) 5 . 0 . 8 o r a b o v e

Ionic CLI & Apache Cordova 2 o r a b o v e

B r o w s e r V e r s i o n

I n t e r n e t E x p l o r e r I E 7 , I E 8 , I E 9

G o o g l e c h r o m e 5 6 . 0 . 2 9 2 4 . 8 7

F i r e F o x 3 4 . 0 a n d h i g h e r
M o b i l e V e r s i o n

A n d r o i d A p a c h e , G r a d l e

I O S X c o d e , A p p l e S D K

D a t a b a s e V e r s i o n

F i r e s t o r e 2 0 1 7

1.3. Functional Requirement

A functional requirement document defines the functionality of a system or pne of its

subsystems. It also depends upon the type of software. Expected users and the type of system
where the software is used.

Functional user requirement may be high-level statements of what the sydtem should do but
functional system requirements should also clearly describe about the system services in detail.

The following are the key fields:

 Purpose of the document

 Scope
 Business Processes
 Functional Requirements
 Data and Integration
 Security Requirements
 Performance
 Data Migration & Conversion
 Some typical functional requirements are:

 Business Rules
 Transaction corrections, adjustments and cancellations
 Administrative functions
 Authentication
 Authorization levels
 Audit Tracking
 External Interfaces
 Certification Requirements
 Reporting Requirements
 Historical Data
 Legal or Regulatory Requirements

2.4 Non-Functional Requirements

Non-functional requirements cover all the remaining requirements which are not covered by the
functional requirements. They specify criteria that judge the operation of a system, rather than
specific behaviour, for example: “Modified data in a database should be updated for all users
accessing it within 2 seconds.”

Some typical non-functional requirements are:

 Performance – for example Response Time, Throughput, Utilization, Static Volumetric

 Scalability
 Capacity
 Availability
 Reliability
 Recoverability
 Maintainability
 Serviceability
 Security
  Regulatory
 Manageability
 Environmental
 Data Integrity
 Usability
 Interoperability

As said above, non-functional requirements specify the system’s ‘quality characteristics’ or

‘quality attributes’.

Many different stakeholders have a vested interest in getting the non-functional requirements
right particularly in the case of large systems where the buyer of the system is not necessarily
also the user of the system.

The importance of non-functional requirements is therefore not to be trifled with. One way of
ensuring that as few as possible non-functional requirements are left out is to use non-functional
requirement groups.
 SYSTEM DESIGN

2.1 Use Case Diagram

 SCREENSHOT

6.1 Landing page for users

..
6.2 User log in page.
6.2 Sign up page for new users
6.3 Vehicle registration details
6.4 Commercial vehicle details.
6.6Coding Arena
 TESTING

The purpose of testing is to discover errors. Testing is the process of trying to discover every
conceivable fault or weakness in a work product. It provides a way to check the functionality of
components, sub-assemblies, assemblies and/or a finished product.

Software testing is an investigation conducted to provide stakeholders with information about

the quality of the software product or service under test. Software testing can also provide an
objective, independent view of the software to allow the business to appreciate and understand
the risks of software implementation. Test techniques include the process of executing a program
or application with the intent of finding software bugs (errors or other defects), and verifying that
the software product is fit for use.

Software testing involves the execution of a software component or system component to

evaluate one or more properties of interest. In general, these properties indicate the extent to
which the component or system under test meets the requirements that guided its design and
development, responds correctly to all kinds of inputs, performs its functions within an
acceptable time,is sufficiently usable, can be installed and run in its intended environments, and
achieves the general result its stakeholders desire.

As the number of possible tests for even simple software components is practically infinite, all
software testing uses some strategy to select tests that are feasible for the available time and
resources. As a result, software testing typically (but not exclusively) attempts to execute a
program or application with the intent of finding software bugs (errors or other defects). The job
of testing is an iterative process as when one bug is fixed, it can illuminate other, deeper bugs, or
can even create new ones.

Software testing can provide objective, independent information about the quality of software
and risk of its failure to users or sponsors.

Software testing can be conducted as soon as executable software (even if partially complete)
exists. The overall approach to software development often determines when and how testing is
conducted. For example, in a phased process, most testing occurs after system requirements have
been defined and then implemented in testable programs. In contrast, under an agile approach,
requirements, programming, and testing are often done concurrently.

There are many approaches available in software testing. Reviews, walkthroughs, or inspections
are referred to as static testing, whereas actually executing programmed code with a given set of
test cases is referred to as dynamic testing.

Static testing is often implicit, as proofreading, plus when programming tools/text editors check
source code structure or compilers (pre-compilers) check syntax and data flow as static program
analysis. Dynamic testing takes place when the program itself is run. Dynamic testing may begin
before the program is 100% complete in order to test particular sections of code and are applied
to discrete functions or modules. Typical techniques for this are either using stubs/drivers or
execution from a debugger environment. Static testing involves verification, whereas dynamic
testing also involves validation.

Types of testing

Broadly speaking, there are at least three levels of testing: unit testing, integration testing, and
system testing. However, a fourth level, acceptance testing, may be included by developers. This
may be in the form of operational acceptance testing or be simple end-user (beta) testing, testing
to ensure the software meets functional expectations. Tests are frequently grouped into one of
these levels by where they are added in the software development process, or by the level of
specificity of the test.

Unit Testing
Unit testing refers to tests that verify the functionality of a specific section of code, usually at the
function level. In an object-oriented environment, this is usually at the class level, and the
minimal unit tests include the constructors and destructors.

These types of tests are usually written by developers as they work on code (white-box style), to
ensure that the specific function is working as expected. One function might have multiple tests,
to catch corner cases or other branches in the code. Unit testing alone cannot verify the
functionality of a piece of software, but rather is used to ensure that the building blocks of the
software work independently from each other.
Unit testing is a software development process that involves a synchronized application of a
broad spectrum of defect prevention and detection strategies in order to reduce software
development risks, time, and costs. It is performed by the software developer or engineer during
the construction phase of the software development lifecycle. Unit testing aims to eliminate
construction errors before code is promoted to additional testing; this strategy is intended to
increase the quality of the resulting software as well as the efficiency of the overall development
process.

Depending on the organization's expectations for software development, unit testing might
include static code analysis, data-flow analysis, metrics analysis, peer code reviews, code
coverage analysis and other software testing practices.

Integration testing

Integration testing is any type of software testing that seeks to verify the interfaces between
components against a software design. Software components may be integrated in an iterative
way or all together ("big bang"). Normally the former is considered a better practice since it
allows interface issues to be located more quickly and fixed.

Integration testing works to expose defects in the interfaces and interaction between integrated
components (modules). Progressively larger groups of tested software components
corresponding to elements of the architectural design are integrated and tested until the software
works as a system.

System testing

System testing tests a completely integrated system to verify that the system meets its
requirements. For example, a system test might involve testing a logon interface, then creating
and editing an entry, plus sending or printing results, followed by summary processing or
deletion (or archiving) of entries, then logoff.

It is the process of exercising software with the intent of ensuring that the software system meets
its requirements and user expectations and does not fail in an unacceptable manner. There are
various types of test. Each test type addresses a specific testing requirement.
TYPES OF TESTING

7.1 Unit Testing

Unit testing involves the design of test cases that validate that the internal
program logic is functioning properly, and that program inputs produce valid
outputs. All decision branches and internal code flow should be validated. It is the
testing of individual software units of the application.

7.2 Integration Testing

Integration tests are designed to test integrated software components to determine
if they actually run as one program. Testing is event driven and is more
concerned with the basic outcome of screens or fields.

7.3 Functional Testing

Functional tests provide systematic demonstrations that functions tested are
available as specified by the business and technical requirements, system
documentation, and user manuals.

7.4 System Testing

System testing ensures that the entire integrated software system meets
requirements. It tests a configuration to ensure known and predictable results. An
example of system testing is the configuration oriented system integration test.

7.5 White Box Testing

White Box Testing is a testing in which in which the software tester has
knowledge of the inner workings, structure and language of the software, or at
least its purpose. It is purpose. It is used to test areas that cannot be reached from
a black box level.

7.6 Acceptance Testing

User Acceptance Testing is a critical phase of any project and requires significant
participation by the end user. It also ensures that the system meets the functional
requirements.

7.7 Output Testing

The output of the project was up to the expectations and the successful output
screens have been placed in the earlier section.
Now, since we actually have something to look at, we need to talk about the testing and
development process for our app. There are four ways to test your app as you develop: in a
desktop WebKit browser, in the iOS or Android simulator, in a mobile browser on your phone,
or as a native app on the phone.

7.9.1 Desktop browser testing

Testing your app in a browser is as simple as running the serve command in your project’s root
folder.

$ ionic serve

This will start a live-reload server for your project. When changes are made to any HTML, CSS,
or JavaScript files, the browser will automatically reload when the files are saved.

7.9.2 Simulator testing

You can also test right in the simulator using the cordova commands from the previous chapter.
For example, to test in the iOS simulator, run:

$ ioniccordova build ios

$ ioniccordova emulate ios

Substitute ios with android for Android testing. If you want to get advanced, you can also open
up the project file for a specific platform by opening the required Xcode or Android Eclipse
project in platforms/PLATFORM inside the root of your project. Then, you can build and test
from inside the platform-specific IDE. Note: if you go this route, I recommend still working
inside of the root www folder, and when you’ve made changes to this folder, run the command:

$ ioniccordova prepare ios

Which will update the ios specific project with the code from the www folder. Note: this will
overwrite any changes you’ve made to the platforms/ios/www and other platform-specific
folders.
7.9.3 Mobile browser testing
We can also test the app directly in a mobile browser. For OS X users, Safari on OS X can
directly debug websites and simulator applications. First you have to enable the remote web
inspector on both the device and Safari on desktop. To do this with iOS 7 and OS X Mavericks,
enable the Web Inspector option in the iOS Settings -> Safari -> Advanced section, and also
enable the Developer Menu in the Advanced section of the Safari OS X settings.

If you are using the local server method from the Desktop testing section and you are on the
same network as the desktop computer, you can connect to the ip address of the desktop
computer to test. So, if our desktop is running a test server at 192.168.1.123:8000, we can just
load that address into our mobile Chrome or Safari to test it.

One problem with testing in a mobile browser is that it’s probably the furthest of the three
options from the actual app experience. This is largely because the browser app is meant for
browsing websites, so it often adds functionality that conflicts with your app. For example,
Chrome and Safari both listen for drag events on the sides of the app which let you switch
between open tabs. They also have issues with the URL bars getting in the way, and some
scrolling behavior is not the same as it is in the web view running in Cordova. It is fine for small
tests, but not recommended for more complex apps.

7.9.4 Testing as a native app

Since we are building a native (or “hybrid”) app, we can (and should!) test it as one. There are
several ways to do this. If you are building for iOS, you’ll need to sign up for an Apple
Developer account to test as a native app on an iPhone or iPad. Unfortunately, this costs $99 per
year (don’t blame us!). Once you have an account and you have set up Xcode with your
certificates to enable device testing, you’ll want to open the Xcode project from platforms/ios/ and
do your testing from Xcode.

Testing on Android is much easier and faster. To test on the device, simply plug it in, and run.
 LIMITATIONS OF PROJECT

Break down of relationships – Fleet managers are bound to develop strong and dependable
relationships with the outsourced maintenance specialist, but the same cannot be said for
other employees, particularly drivers. If operations are kept in-house, then a driver can go
to the manager directly with any questions, concerns or problems. Howev er, adding a
third-party into this relationship makes matters a little bit more complicated. In addition to
this drawback, previous relationships between the in-house fleet manager and dealerships,
suppliers, insurers and accountants will break down too.

Loss of insight – If fleet maintenance and management is outsourced, there is a danger

that previous insights and control over operations will be lost. This is even more plausible
if previous in-house responsibilities are absorbed into another department. Although
budget and efficiency considerations take top priority, it is important to establish clear
lines of communication with any outsourced provider in order to receive detailed feedback
about operations.

Accountability issues – Ultimately, the in-house fleet manager will be responsible for
every aspect of maintenance and management, even if certain tasks and functions are
outsourced. But, if a regrettable or difficult incident occurs, it is easy to pass the buck and
shy away from accountability. For the main aspects of fleet maintenance and management,
it is advisable to have in-house members of staff in place. However, more specific tasks
such as purchasing handling, legal requirements, accident reporting, and ongoing repairs
can be outsourced.
 FUTURE SCOPE OF PROJECT

• Online tracking of the vehicle:-

-details of the driver which is handling the vehicle at that particular

time.

- place to which it has reached

• Uploading all the documents online so that if requirement arises the soft copy of the
document can be produced intead of original copy.
• Gmail notifications which will remind the users of the expiry date 10 days prior.
• To insert picture of each vehicle.

6. References

10.1 http:// www.google.co.in

10.2 https://stackoverflow.com/

10.3 https://getbootstrap.com/
10.4 https://www.tutorialspoint.com

10.5 https://spring.io/projects/spring-boot

10.6 https://docs.spring.io/springdata/jpa/docs/1.5.0.RC1/reference/.../jpa.repositorie
s.html

10.7 https://www.w3schools.com/

10.8 https://jquery.com/

10.9 https://www.javatpoint.com/