FleetMgtSystem PDF

Automatic Fleet Management System
A Thesis submitted in partial fulfillment of the requirements for the degree

of
Master of Engineering in Software Engineering,

by
Sanat Ghoshal
Examination Roll: M4SWE10-21
Class Roll: 000811002025 of 2008-09
University Registration No. 104340 of 2008-09
Department of Information Technology
Jadavpur University
Under the supervision of
Prof. (Dr.) Samiran Chattopadhyay

Jadavpur University,Kolkata
II
JADAVPUR UNIVERSITY
FACULTY OF ENGINEERING AND TECHNOLOGY
CERTIFICATE OF APPROVAL
(Only in case the thesis is approved)
The thesis at instance is hereby approved as a creditable study of an

Engineering subject carried out and presented in a manner satisfactory to
warrant its acceptance as a prerequisite to the degree for which it has been
submitted. It is understood that by this approval the undersigned do not
necessarily endorse approve any statement made, opinion expressed or
conclusion drawn therein, but approve this thesis for the purpose for which it
is submitted.
Examiners:
(Signature of the examiner)
( Signature of the supervisor )
III
Acknowledgements
The writing of this thesis as well as the related work has been a long journey
with input from many individuals, right from the first day till the finishing of the
thesis. With my most sincere respect and gratitude, I would like to thank Prof.
Samiran Chattopadhyay, my supervisor, for his constant support throughout
the duration of this project. His motivation always gave me the required inputs
and momentum to continue with my work, without which the project work
would not have taken its current shape. His valuable suggestions and
numerous discussions have always inspired new ways of thinking and giving
me a new dimension. As a person too, I will never forget his immense support
in times of my personal crisis, without which I would most definitely have
failed to complete this thesis. I feel deeply honoured that I got this opportunity
to work with him.
I am grateful to Prof. Sandip Das, Indian Statistical Institute, Kolkata for his
overwhelming encouragement and support. I would also like to thank all
faculties and departmental members and my batch-mates of Information
Technology department and who helped me directly or indirectly in this
milestone achievement.
Last, but not the least, I would like to thank my mother, wife, daughter and
brothers, for their unconditional love, encouragement and patience that keep
me motivated and helped to succeed.
Sanat Ghoshal
Examination Roll: M4SWE10-21
Class Roll: 000811002025 of 2008-09
University Registration No. 104340 of 2008-09
IV
Abstract
This thesis work is mainly concerned with the Automatic Fleet Management
System. Rapid development of modern vehicle systems brings tremendous
challenges to the intelligent fleet management system. Automatic Fleet
management System (AFMS) is such an intelligent model that manages a
company's vehicle fleet mainly concern with the vehicles telematic services.
Telematic services are related to the functionality of vehicles internal
electronics, wireless communications, and information technologies. Tracking
and monitoring the entire fleets movements is controlled by the GPS system.
GPS is a satellite-based navigation system that works by receiving raw data
from satellites and then calculating physical locations of the vehicles. It is the
most effective solution in terms of cost and real time basis data collection for
AFMS. This system allows viewing the present and the past positions
recorded for a vehicle or a group of vehicles on Goggle Map or by other map
providers through the internet. Some live tracking systems that are available
nowadays used SMS for their communications to the server which turned out
to be expensive as SMS are used for communication to devices only. AFMS
model has been used the Global System for Mobile Communications (GSM),
General Packet Radio Service (GPRS) for mobile communication which
made the system a low cost tracking solution for locating an objects position
and status. This system is very much useful for controlling fleets security
(alarm alert, engine starting, localizing), reckless driving, rescue operation
and optimize the use of fleets with related resources. So AFMS is an
integrating system which glues different technologies: GPS used for locating
the physical position, speed and status of the vehicles, GSM/GPRS mobile
communication used for tracking the vehicles and to send SMS, Application
server receives the data sent by the GSM/GPRS system and store it to the
database system and the web based user interface (with Internet with Goggle
Map) used to watch and control the overall system. I have designed,
developed, and tested a rudimentary AFMS system and the details are
included in this thesis.
Key Terms: GPS, GPRS, GSM, NMEA, IMEI, Goggle Map, Application server,
Database server, VTU, Latitude, Longitude, Reverse Geocode
Table of Contents
Acknowledgements
Abstract
Table of contents
List of figures
List of tables
IV
V
VI
VIII
IX
Chapter 1 Introduction
1.1 Background
1.2 Thesis Objective
1.3 Overall functional activities of this system
1.4 Thesis contribution

1.5 Thesis Structure
Chapter 2 Literature Survey
2.1 Introduction
2.2 Survey of Research work in this field
2.2.1 Traffic surveillance technologies
2.2.2 Road Transportation Management using
GIS - vehicle routing and tracking
2.2.3 Designing Automated Vehicle Location
Systems for Archived Data Analysis
2.2.4 Cost Effective GPS-GPRS Based Object
Tracking System
2.2.5 Enhanced Mobile Asset Tracking with
Telemetry Function
2.3 Case study
2.3.1 Delhi Transport Corporation (DTC)
2.3.2 Cost Effective GPS-GPRS Based Object Tracking System
2.4 Summary of Literature survey
Chapter 3 Systems Model and Technology
3.1 Overview
3.2 Communication System
3.3 Fleet Management Systems
3.4 Technology Overview
Chapter 4 System Design, Architecture
4.1 User Interface
4.1.1 N-tier Architecture
4.1.2 MVC Architecture
4.2 Activity Diagram
4.3 E-R Diagram of the system
4.4 Database Schema
VI
2
2
3
4
6
6
7
7
7
7
7
7
8
8
8
8
9
10
11
12
12
13
15
15
15
16
28
29
4.5 Use Case Diagram of the system

4.6 Algorithm embedded in this model
39
43
Chapter 5 Implementation Details

5.1 Introduction
46
5.2 Software Components
47
5..3 Hardware components
48
5.4 Protocol used for communication
48
5.4.1 GPS Protocol
48
5.4.2 HTTP Protocol
48
5.5 Detail description of the Implementation
48
5.6 Evaluating the performance benefits of the Automatic Fleet
Management System
53
Chapter 6 System Simulation
6.1 Overview
6.2 Flow Diagram
6.3 Some execution snapshots of this system
56
57
58
Chapter 7
Conclusions
67
APPENDIX
68
APPENDIX
71
APPENDIX
73
REFERNCES
78
VII
List of Figures
Figure contents
Page #
MVC Architecture
Activity diagram shows how to interpret GPS received data (Fig-07)
Activity diagrams show how to create and view device groups(Fig-08)
Activity diagram for mapping real time and historical device(s) (Fig-09)
Activity diagrams show about the login and logout from the AFMS
system(Fig-10)
Activity diagrams show how to create and view an administrator
account in the AFMS system(Fig-11)
Activity diagrams show how to modify and deactivate an account
(Fig-12)
Activity diagrams show how to create and view a device by an
administrator (Fig-13)
Activity diagrams show how to create and view Geofences (Fig-14)
Activity diagrams show how an administrator can edit and delete
Geofences (Fig-15)
Activity diagram shows how to create a way point(Fig-16)
Activity diagram shows how to generate reports by a user(Fig-17)
ER diagram of the AFMS system (Fig-18)
Use case diagram users access control logic (Fig-19)
Use case diagram administrators behavior (Fig-20)
Use case diagram communication server (Fig-21)
Route layout graph (Fig-21(a))
Implementation diagram of AFMS (Fig-22)
Flow diagram of the overall system (Fig-23)
Application server functional flow diagram (Fig-24)
Movement of a vehicle with different seed (Fig-25)
Performance graph of vehicles (Fig-26)
System simulation overview (Fig-27)
Simulation flow diagram (Fig-28)
Login screen of the system Fig-29
Main menu screen (Fig-30)
Vehicle Map screen (Fig-31)
Group Vehicle Map screen (Fig-32)
Summary report screen (Fig-33)
Account Admin screen (Fig-34)
View/Edit User Information screen (Fig-35)
Geozone area on map (Fig-36)
GPS satellite (picture collected from
http://www.ehow.com/facts_5005974_what-waypoint-gps.html ) Fig-37
VIII
16
17
18
19
20
21
22
23
24
25
26
27
28
40
41
42
43
46
49
50
52
53
56
57
59
60
61
62
63
64
65
66
69
List of Tables
Table contents
Page #
Geocode Table
51
Comparative study between GPRS Based System and SMS Based System
71
IX
Chapter 1
Introduction
1.1 Background
The increased availability of data on fleet makes the management organization a
significant pressure mainly on the fleet managers and stuff to maintain and produce a
wide array of management information for employees, fleet users, finance and audit
departments, management decision makers and general public that leads to grow
telematic service oriented fleet management system. The security and optimize use of
the vehicles is a major challenge for fleet managers and these requirements are to be
sufficiently informed in a timely manner. So the management and administrator for
administration activities of almost every fleet operation have felt the impact of
technology. Some of the best fleet managers in the industry have addressed this
requirement by implementing software solution that pushes information to
stakeholders on a regular schedule. Push technology is a set of technologies used
to send information to a client without the client requesting it. With the advent of
Automatic Fleet Management System, vehicle owners get better opportunities to
control over the vehicles deployment and usage. A great amount of accountability is
introduced here. Such a system that can track the whereabouts of the vehicles and
keep their traveling history would provide the fleet owners an efficient and convenient
system and can make good coordination with their staffs. So better productivity from
both fleet owners and staffs can be expected here. This system also helps the
transporters and traders to make their payment on consignment of their goods
because the system can provide real time status after each interval. Actually, this is a
web-based system that allows clients to track the progress of their consignment in
transit. So such a reliable, real-time, automated system can make improvement on
the relationship of the fleet owners with their customers and this would mean
opportunities for the business to grow. Therefore, it the most convenient and efficient
platform to provide services to the customers and to control over fleet owners.
Automatic Vehicle Location systems have been used by bus transit agencies in the United
States since 1969. Now it is an emerging technology and has been used in many countries
like U.K , Australia, Saudi Arabia, Japan, German, Russia, France and many other
countries.
In India Fleet Management System has also been used in different regions and as a
ready reference a list is given below:

Delhi Transport Corporation, Delhi

Northern Coalfields Ltd
Andhra Pradesh Road Transport Corporation, AP
Accord Software & Systems Private Limited, Bangalore, India
The state-of-art of this technology is nested within the broader field of Intelligent
Transportation Systems (ITS) and nowadays although developed in some areas it can be
classified as emerging technology. Various technologies have been applied over the
2
years however the reducing costs and increased precision afforded by GPS receivers now
make this technology a better choice. AFMS is achieved by integrating a GPS receiver
with the onboard radio unit. The AFMS can be configured to report vehicle location
(latitude and longitude) at pre-determined intervals (e.g., 5 min), when a voice or a
data message is sent from the vehicle. The vehicle location data are sent wirelessly
over the radio network and can be overlaid on a GIS map on the dispatcher's
computer. The AFMS information also provides operation supervisors a tool to
monitor on-time performance, which is randomly conducted by a supervisor waiting at
a scheduled stop. The AFMS, with recorded pick-up and drop-off times, provides
complete records for assessing on-time performance.
1.2 Thesis Objective

The Objective of Automatic Fleet Management System is to reduce risk, improve
safety and security, and optimize fleet operations with real-time basis. The aim of
Automatic Fleet Management system is to automate the planning and usage of the
fleet in the most efficient way to allow the optimum usage of the vehicles in order to
provide even better service to people and guide alternative possible ways to reach a
destination.
The advantage of GPS is that it is free to use as stated in the Presidential Decision
Document (29 March 1996) and by Congress in the 1998 Public Law (105-85). Both
state that U.S. will continue to provide the GPS Standard Positioning Service for
peaceful civil, commercial and scientific use on a continuous, worldwide basis, free of
cost direct user fees. Another advantage of GPS system is that the small
portable GPS receivers have become very affordable and can be fitted on to mobile
assets easily and Lower costs have led to use of GPS in a wide variety of applications.
Most of the software components used in this system are free (free source code) to
use. So the objective is my thesis is to take the advantages of GPS with GPRS/GSM
technology to find the location of a fleet and to provide a new dimension for the web
based applications with low cost opportunity that can process it and make it to an
actionable form.
The objectives of the Automatic Fleet Management System are as follows:
Integration of GPS with GIS map of a particular region for tracking of vehicles
on a real time basis with two way messaging including distress messaging
between the vehicle and the control station
To monitor whether the buses are adhering to its scheduled route and time
table through out the route and identify if there are any deviations.
To monitor whether the buses are giving halt at all without the scheduled bus
stops, this is resulting in loss of revenue.
Automatic generation, collection, storage and retrieval and analysis of data &
information helps to eliminate the human related errors involved in collecting of
such data.
Development of custom on-line queries
Integration with the database pertaining to employees, buses, bus stages, fare
stages, depots, school bus routes etc.
It can be used as a decision support system for implementation of this

Transportation Model
Generation of exception reports like deviation from schedule route, timing,
Missing Bus stops, Punctuality factor etc. based on captured vehicle data.
1.3 Overall functional activities of this system

AFMS is an online fleet management
system which provides a robust vehicle
interface that connects directly to the
vehicle electronics, enabling it to access
online a wide range of vehicle operating
data such as odometer readings, fuel levels,
oil pressure, airbag deployment, diagnostic
trouble codes, and vehicle operation
devices like specialized equipment
Vehicle Tracking Unit
(VTU) on each vehicle Fig-01
Switches along with the vehicle location. The vehicle's data is then sent wirelessly
using mobile communication through the SIM of the Vehicle Tracking Unit (VTU) to
the client's server which is an application server (actually a communication server).
The function of the communication server is to receive the data generated as an
event object after each interval and send it to the database server where the data is
stored and used to provide critical information including: time and attendance reports
for drivers , mileage reports, real-time vehicle location, crash notification, remote
diagnostics and warnings for abnormal vehicle conditions. The following benefits can
be provided by this AFMS model:
Increased overall dispatching and operating efficiency

More reliable service, promoting increased riders desire
Quicker response to service disruptions
Inputs to passenger information systems
Increased driver and passenger safety and security
Quicker notice of mechanical problems with the vehicles, reducing maintenance
costs
Efficient, optimized, flexible, and user-preferred route structures
Dispatching of emergency vehicles to Breakdown vehicles or vehicles in
distress, whenever it is sought
To provide better path to reach the destination when a vehicle is in problem
with minimum hop
A simple flow diagram how AFMS works
Satellite
GPS
Microwave
Signal
GPS
Antenna
GSM
Modem
GSM
Antenna
In-Vehicle Equipment
GPS
GSM
Modem
Application
Server
In-vehicle equipment
Internet
Database
Server
User
Interface
Box diagram representation of the system (fig-02)

GPS Satellites emit microwave signals which enable GPS receivers to calculate
position ( Latitude / Longitude position) , time, direction, Speed and Status ( Stop /
Running / Toeing position ) of the vehicles from their VTU ( Vehicle Tracking Unit )
and sends it to the Communication Server through GSM / GPRS technology . Inside
the VTU there is a SIM which helps to communicate with the Application Server which
in turn sends the information to the Database Server. User Application Program it is a
web based application program through which user can interface with the Database
server using Internet are used for controlling and taking decision of the vehicles .
1.4
Thesis Contribution
In this dissertation following things have been put together

a) Reviewed different technologies and model and the practical constraints
b) Rescue passengers from a vehicle to reach the destination with minimum cost :
Main concern of this thesis work is to rescue passengers from a vehicle to reach
their destination with minimum cost. When a vehicle is not functioning i.e. out of
service due to any reason, Automatic Fleet Management System can provide a
convenient way to guide the passengers to reach their proper destination. As
AFMS can track all the vehicles movement and their routes so it can provide
alternative vehicle routes through this point with minimum hop that is to reach the
destination with minimum vehicle changes. To provide this facility an algorithm has
been developed and defined in the design part of this thesis.
1.5 Thesis Structure

Chapter 1 states thesis background, objectives, overall functional activities, and
contribution in thesis.
Chapter 2 mentioned the relevant literature that have been followed for problem of
interest and help to find out solution to the problem
Chapter 3 focuses on the Models and Technologies used in Automatic Fleet
management System. That is, why this model and technology is better to use with
respect to reliability, efficiency and reduce cost effectively.
The main concern of Chapter 4 is the System Design and Implementation. Explain in
detail different architectural design concepts used in this system and the algorithm
developed as a thesis work in this system.
Chapter 5 mentioned the detail Implementation steps. This chapter specifies the main
hardware and software requirement details.
Chapter 6 focuses on the system simulation related to the thesis work. This chapter
depicts step-by-step expiation of the execution of this system.
Conclusion of this thesis work is defined in Chapter 7
Three appendixes and reference of URLs included in this paper for related
information of this thesis work.
Chapter 2
Literature Survey
2.1
Introduction
A review of existing literature was performed to support the study undertaken in this
thesis. A general survey was first made stating from the past research efforts in
developing traffic surveillance technologies used for vehicle tracking systems to
telematic function based automatic object tracking system.
2.2 Survey of Research Work in this field

Researchers have tested a wide array of technologies in an attempt to find improved
methods of monitoring and controlling vehicles fleet. A brief survey of technologies
explored during the past decade mention below.
2.2.1
Traffic surveillance technologies.
The amount of attention given to the research field of traffic surveillance report during
the year of 1967 to 1975 suggests that a surveillance system which can provide
reliable and accurate travel time 10 data would have great potential. The research
communitys interest in developing reliable and accurate surveillance systems is a
primary motivation for the evaluation of any system.
2.2.2
Road Transportation Management using GIS - vehicle

routing and tracking
A geographic information system (GIS) integrates hardware, software, and data for
capturing, managing, analyzing, and displaying GUI based all forms of geographically
referenced information. Using GIS in the field of transportation opens up a new wide
range of possible applications, as diverse as the field of transportation itself. Whether
these are cars and trucks along a road, trains along a track, ships across the sea or
airplanes in the sky, all applications have one thing in common: These are objects
that move along a path in space. A GIS can provide valuable tools for managing
these objects in a spatially referenced context, viewing the paths as a transportation
network. This system attempts to render the extent of existing GIS applications within
road transportation, and critically assess their appropriateness and potential.
2.2.3
DESIGNING AUTOMATED VEHICLE LOCATION SYSTEMS

FOR ARCHIVED DATA ANALYSIS
Automatic vehicle location (AVL) and other automated data collection systems
together can provide a rich and extensive database that can be analyzed to improve
transit management and performance. In the past, many such systems have failed to
7
provide a good data archive, while others have had success. Through the use of an
extensive survey and in-depth case studies of nine transit agencies, the key factor in
system design that help to determine whether a data collection system will provide the
useful data archive that many agencies desire are examined. In issues related to
design of the data collection system itself, the focus is on five different levels of spatial
detail. Again the issues related to database design are organizational issues.
2.2.4
Cost Effective GPS-GPRS Based Object Tracking System
The main concern of this system implementation is low cost object tracking system
using GPS and GPRS. The system allows a user to view the present and the past
positions recorded of a target object on Goggle Map through the internet. The system
reads the current position of the object using GPS, the data is sent via GPRS service
from the GSM network towards a web server using HTTP protocol. The objects
position data is then stored in the database for live and past tracking. A web
application is developed along with a database server and Goggle Map is embedded
with it.
2.2.5
Enhanced Mobile Asset Tracking with Telematic Function
Enhanced Mobile Asset Tracking with telematic function is the newest and one of the
most advanced systems in Asset Tracking Technology. It uses the GPS system
together with the GSM (GPRS/ICS - Internet Communications Services) infrastructure
to bring back information to central control. It is an efficient and reliable system and
can be thought of as an emerging technology for real time tracking system.
2.3 Case Study

2.3.1
Case Study: Delhi Transport Corporation (DTC)
As a case study in India, Delhi Transport Corporation is the one of the largest City Road
Transport system. DTC has a fleet of around 15,000 vehicles on 800 routes from 33 depots
all over the state of Delhi. CMC has Designed, Developed and Implemented the Automatic
Fleet Management System that include many features like Vehicle Tracking System,
Application software for billing, Operational Transportation Model for scheduling of buses and
integration of Smart Card Reader with the Vehicle Tracking System, provision for Real Time
Passenger Information System to Delhi Transport Corporation. The AFMS system in Delhi is
currently operational from two depots for 200 buses since last two years.
Objectives
The objectives of the Automatic Fleet Management System as provided by DTC are as
follows:
Integration of GPS with GIS map of Delhi for tracking of vehicles on a real time
basis with both messaging including distress messaging between the vehicle
and the control station
To monitor whether the buses are running according to its scheduled route.
8
To monitor whether the buses are giving halt at all the scheduled bus stops that
is resulting in loss of revenue.
Automatic generation, collection, storage and retrieval and analysis of data
that eliminate the human related errors involved in collecting of such data.
Development of on-line queries for DTC related to GIS
Integration with the database of DTC pertaining to employees, buses, bus
stages, fare stages, depots, school bus routes & stages
Used as a decision support system for implementation of Transport Model by
DTC
Generation of exception reports like deviation from schedule route, timing,
Missing Bus stops, Punctuality factor etc. based on captured vehicle data.
Provide billing facility to generate automatically billing details for the buses.
distress, whenever it is sought.
Provision of Smart Card Readers being supplied by Delhi Metro Rail
Corporation.
Help in working out realistic schedules according to traffic conditions based on
speed of bus during different time of the day and at different routes
Provision to provide Real Time Passenger Information System both within the
bus as well at major Terminuses.
2.3.2
Case Study: Cost Effective GPS-GPRS Based Object Tracking

System
This paper proposes and implements a low cost object tracking system using GPS
and GPRS. The system allows users to view the present and the past positions
recorded of a target object on Goggle Map through the internet. The system reads the
current physical position of the object using GPS, the data is sent via GPRS service
from the GSM network towards a web server using the POST method of the HTTP
protocol. The objects position data is then stored in the database for live and past
tracking. A web application is developed using PHP, JavaScript, Ajax and MySQL
with the Goggle Map as a map provider. The existing live tracking systems that are
available now a days use SMS for the communication to the server which turned out
to be expensive. (SMS are used for communication to device). We have used the
GPRS service which made our system a low cost tracking solution for localizing an
object position and status. This system is very useful for car theft situations (alarm
alert, engine starting, localizing), for adolescent drivers being watched and monitored
by parents (speed limit exceeding, leaving a specific area), as well as this can be
used for human and pet tracking.
Objectives
Objective of this paper is to present a low cost tracking system using GPS and GPRS
of GSM network, suitable for wide range of applications all over the world. The
combination of the GPS and GPRS provides continuous and real time tracking. The
cost is much lower compared to SMS based tracking systems. Free Google map and
the use of HTTP protocol as data sending method reduces the monthly bundle cost
9
for the individual user, group users, and also for the small business owners. It is
expected that the full implementation of the proposed system would ultimately
substitute the traditional and costly SMS based tracking systems.
2.4
Summary of Literature survey
Enhanced Mobile Asset Tracking with Telemetry Function is the best solution what I
find so far from the literature survey. Accordingly I adopt such a robust system in my
thesis work with the associated technologies and giving a proper shape to provide
extra feature as defined in the chapter 6 algorithm parts.
In this thesis work I seek to address the following issues
distress, whenever it is sought. So a rescue van/vehicle is sent that is in the
shortest distance from the vehicle which is in distress. But only the parameter
shortest distance is not enough to solve the problem because of the following
reasons :
a) Deployment of rescue vehicles solely is more cost effective
b) The rescue vehicle may reach in late because of network traffic
So dispatching a nearest vehicle of the route to Breakdown vehicles is the best

choice. Although it is a good solution but it may have the following problems:
a) The nearest vehicle may not reach to the desired destination as the
passengers of this vehicle may go to another destination. So the
distressed passengers have to search for another vehicle after traveling
a particular distance
b) The nearest vehicle may not have the capacity to accommodate the
distressed passengers
As AFMS is a decision support system and decision has to be taken depending
on some factors :
a) Road maps
b) Traffic congestion
c) Number of vehicles etc.
So its application may vary in different regions and with different requirements.
A list of urls is given in the reference as literary survey to prepare this thesis work.
10
Chapter 3
Systems Model and Technology
3.1
overview
AFMS is a Decision Support System. It glues different technologies like

GSM/GPRS based mobile communication, client-server web based n-tier
architecture with GPS based satellite communication to provide a reliable, secure,
more cost effective, real time basis platform. So the overall system model stands
on Mobile Communication with Object Oriented Technology.
GPS
GPRS/GSM
Internet
Vehicle
Mobile Tower
Communication
server
Applications
Running for User
Interface
Database
Server
Overall functionality of the Automatic Fleet Management System (Fig-03)
11
The system uses the GPS system together with the GSM (GPRS/ICS - Internet
Communications Services) infrastructure to bring back information to central control
Room.
3.2
Communication System
In any vehicle tracking system, the communications infrastructure is the main

concern this is because it is this that brings information back to central control
station. This model uses the GSM infrastructure and in particular the GPRS/ICS
(Generalized Packet Radio Service / Internet Communications Services) function
of GSM. This function allows mobile phone users to send Multimedia Messages
(MMS) and to surf the Internet. Google map is used for mapping the location.
Vehicle Tracking Unit (VTU) is used for providing addition information to the
application server which in turn store in the database server for taking necessary
control of the vehicle in future.
This SIM is
often
called
VTSIM ( vehicle
tracking SIM ) it
is configured by
the SMS Server
SIM
Vehicle Tracking
Unit Unit
Fig-04
3.3
Fleet Management Systems
Fleet Management Systems is responsible for bringing back data from the vehicle to
central control station. The standard information that it sends would be Location
Information about the vehicle (Longitude/Latitude), Altitude, Speed and Distance
traveled between two reported points. This information is derived purely from the GPS
system and no connection to the vehicle is required apart from the power supply.
To bring back other information, for example, temperature and tire pressure, vehicle
running status etc. additional equipment is required and it is the VTU (Vehicle
Tracking Unit) in which such vehicles electrical systems are embedded.
12
3.4
Technology
A brief overview of different technologies used in the system is given below:
GPS Technology:
Global Positioning System (GPS) technology is a Global Navigation Satellite System
developed by the US Depart of Defense .System is formed from a constellation of 24
Satellites that orbit the Earth at an altitude of 20,000 Km every 12 Hours .Satellites
emits microwave signals which enable GPS receivers to calculate position, time,
speed and direction. Small Portable GPS Receivers have become very affordable and
can be fitted on to mobile assets .Lower costs have led to use of GPS in a wide
variety of applications .
The GPS receiver captures position data from the satellites, computes the position of
the vehicle and sends this information to a central base station, using SMS. This
information is collected by the built-in web-server at the base station. Then location
data can be stored to a database server and if the vehicle is out of range of the
cellular operator it can be retrieved later. The Telematic Function means that it can
bring back information of any measurable quantity from the vehicle. Some examples
would be temperature in a refrigerated container, tire pressure, weight of the cargo it
is carrying. Generally, any electronically measurable quantity can be sent back to
central control station.
GPRS Technology:
General packet radio service (GPRS) is a packet oriented mobile data service
available to users of the 2G cellular communication systems global system for mobile
communications (GSM), as well as in the 3G systems. In 2G systems, GPRS
provides data rates of 56-114 kbit/s. Charge of GPRS data transfer is typically per
megabyte of traffic transferred, while data communication via traditional circuit
switching is billed per minute of connection time, independent of whether the users
are actually using the capacity or keep in an idle state. GPRS is a best-effort packet
switched service, as opposed to circuit switching, where a certain quality of service
(Quos) is guaranteed during the connection for non-mobile users.
2G cellular systems combined with GPRS are often called as 2.5G, that is, a
technology between the second (2G) and third (3G) generations of mobile telephony.
It provides moderate speed of data transfer, following unused time division multiple
access (TDMA) channels in, for example, the GSM system. Originally there was some
thought to extend GPRS to cover other standards, but instead those networks are
being converted to use the GSM standard, so that GSM is the only kind of network
where GPRS is in use. GPRS is integrated into GSM Released in 1997 and newer
released versions. It was originally standardized by European Telecommunications
Standards Institute (ETSI), but now forwarded by the 3rd Generation Partnership
Project (3GPP).
13
GPRS was developed as a GSM response to the earlier CDPD and i-mode packet
switched cellular technologies.
Services offered
GPRS extends the GSM circuit switched data capabilities and makes the following
services possible:
Provides "Always on" internet access

Facilitate Multimedia messaging service (MMS)
Push to talk over cellular (PoC/PTT)
Provides instant messaging
Internet applications for smart devices through wireless application protocol
(WAP)
Point-to-point (P2P) service: inter-networking with the Internet (IP) protocol
If SMS over GPRS is used, an SMS transmission speed of about 30 SMS messages
per minute may be achieved. This is much faster than using the ordinary SMS over
GSM, whose SMS transmission speed is about 6 to 10 SMS messages per minute. A
comparative study between GPRS/ICS Based System and SMS Based System is
mention in appendix B.
Protocols supported
GPRS supports the following protocols:
Internet protocol (IP). In practice, mobile built-in browsers use IPv4 since IPv6
is not yet popular and functioning every region.
Point-to-point protocol (PPP). In this mode PPP is often not supported by the
mobile phone operator but if the mobile is used as a modem to the connected
computer, PPP can be used to tunnel IP to the phone. This allows an IP
address to be assigned dynamically to the mobile equipments.
X.25 connections. This is typically used for applications like wireless based
terminals(workstations), although it has been removed from the standard. X.25
still it can be supported over PPP, or even over IP, but doing this requires either
a network based router to perform encapsulation or embedding intelligence to
the end-device/terminal; e.g., user equipment (UE).
When TCP/IP is used, each phone can have one or more IP addresses allocated.
GPRS will store and forward the IP packets to the phone during cell handover (when
we move from one cell to another). TCP handles any packet loss (e.g. due to a radio
noise induced pause) resulting in a temporary throttling in transmission speed.
Object Oriented model is used in the software communication part to develop this
system. So java is the best choice to develop this platform as a language. Here java
is considered as a language to develop this system because of its robustness,
adoptability features, platform independency, and enterprise web based application
development capabilities. Detail design of this model is defied in the next chapter.
14
Chapter 4 System Architecture, Design and Implementation

4.1 User Interface
4.1.1 N-tier architecture
User
Interface
( Web
Browser )
Application
Server
( Sun one
Application
Server /
NetBeans )
Web Server
( Apache
Tom Cat )
Database
Server
(MySql )
Fig-05
In n-tier architecture each tier is related to specific process. Users HTTP request
sends to Web Server through web browser. Web browser forwards the request to the
Application server to communicate and to execute the Business Logic that have in the
system. The Application server in turn may require some data from Database server
to fetch and finally the result is send back to the users browser as an HTTP response.
4.1.2
MVC Architecture
MVC architecture is the fundamental design for this web based application system.
Essentially, MVC breaks GUI components into three elements: Model, View, and
Controller. Each of these elements plays a crucial role in how the components behave.
MODEL : The model encompasses the state data for each components used in the
system. Different types of models exist for different types of components, e.g. a menu
component may simply contain a list of menu items that a user can select from. This
information remains same no matter how the component is painted on the screen;
model data is always independent of component visualization.
VIEW : The view refers to how we see the components on the screen, e.g. how views
can make difference by looking at an application window on two different GUI
platforms. Because different window frames format exist in different platform.
CONTROLLER : This component is the main concern of the user interface that
dictates how the components interact with events. Events may come from mouse
click, gaining and losing focus, acceptance of GPRS data. So controller dictates how
each component reacts to the generated events. For example, after login to this
15
system when we select vehicle map submenu from the list of menu bar and set the
date a map will be displayed on the screen. Here the controller part is: (1) select the
submenu and (2) set date and the view part is the map displayed on the screen.
A brief MVC architecture of this system is given below:
Controller
(1) POST
( 2) Dispatcher
(AccountLogin.java
)
LoginSession.jsp
(4) FORWARD
Business
Logic Action
(3) Update
Client
Browser
(6) Response
View
(5) Extract
( jsp files)
Model
DataSet &
Data Tables
Model View Controller Architecture (MVC) (Fig-06)
4.2
Activity Diagram
An Activity diagram shows the flow from activity to activity within a system. As it
is an object oriented, mobile communication system its dynamic views can be
shown by some activity diagrams of this system.
Once the device (VTU) is configured properly, it can be installed into the vehicle
(power source and other sensors are to be connected properly). Now, the device is
ready to send event data to the application/communication server through GPRS after
each interval (as configured). The communication server, on getting the event data,
would perform several operations such as - parsing the data packet and extracting
information like latitude, longitude, timestamp, status code, speed etc. Depending on
the latitude/longitude value a reverse geo-coder method is followed to obtain the
16
human understandable address format and then inserting the event data into the
database. The following activity diagram shows how to interpret GPS received data.
Activity diagram shows how to interpret GPS received data (Fig-07)
When vehicles are moving in different routes, it is tracked by this system due the
device (VTU) attached with it. So devices can be grouped together to watch and
control easily. Device groups represent a functional grouping of various devices under
an account. If no group is defined for the account, the default group is all. The two
17
following diagrams show how to create a device group and how we can view the
groups of devices.
Activity diagrams show how to create and view device groups(Fig-08)
18
When vehicles are tracked and displayed their location on the map, the current real
data along with the historical positional data is required. The two following diagrams
show how to track the devices (vehicles) using map for real time and historical
device(s) data.
Activity diagram for mapping real time and historical device(s) (Fig-09)
19
Authorized users can only login to the system and can explore all functional activities
of this system. The following two activity diagrams show how to login and logout from
the system.
.
Activity diagrams show about the login and logout from the AFMS
system(Fig-10)
20
When a user login to the system, he/she can create another account. Accounts are of
two types (1) Administrator account and (2) User account. An Administrator account
has all privileges to access and control all the system resources. An Administrator can
create another user but a normal user cant do it. The following two activity diagrams
show how to create and view administrative account.
Activity diagrams show how to create and view an administrator account

in the AFMS system(Fig-11)
21
An account can be modified by modifying (i.e. by editing) the ACL (Access Control
Logic) given to the account. It can also be deactivated by the administrator. The
following two activity diagrams show how to modify and deactivate an account.
Activity diagrams show how to modify and deactivate an account (Fig-12)
22
When a new vehicle joins in this fleet management, the device attached to the vehicle
must be configured and given to some user(s) account(s) to track and control over it.
The following diagrams show how to create and view a device by an administrator.
Activity diagrams show how to create and view a device by an administrator

(Fig-13)
23
Geo-fence is a rectangle, defined by the 2 vertices of its south-west to north-east

(SW-NE) diagonal. Each account can have several geo-fences defined for it but each
device can have only one geo-fence assigned to it (a hardware feature). A User can
create a geo-fence, which can then be uploaded remotely to the hardware. This
(hardware) feature will generate alerts whenever the vehicle enters or leaves the
designated geographical area (as defined by the user). The following diagrams show
how to create and view Geofences by a user.
Activity diagrams show how to create and view Geofences (Fig-14)
24
After creation of Geofences an administrator can edit i.e. modify it and delete it. The
Following activity diagrams show how to edit and delete Geofences by an
Administrator.
Activity diagrams show how an administrator can edit and delete Geofences
(Fig-15)
25
Way-Point is a circular area and a user can define these circular areas (point + radius)
on map. This feature would allow the user to configure points along the route that the
vehicle must travel to, and receive alerts on arrival and departure from these points.
This feature can be used to know what part of the journey and in what time frame has
been accomplished by the vehicle or for example to set up arrival notification if the
vehicle is x km away from a warehouse etc. The Following activity diagram shows
how to create a way point.
Activity diagram shows how to create a way point(Fig-16)
26
In the AFMS system database server stores all the records of the fleets for generating
reports. A user can generate reports about a vehicle or a group of vehicles from a
date range and displayed in HTML/TEXT format. The following activity diagram shows
how to generate reports by a user.
Activity diagram shows how to generate reports by a user(Fig-17)
27
4.3
E-R Diagram of the system
The structure of database often called database schema is specified in one of many
languages or notations suitable for expressing designs. After due consideration of the
notation, the design is committed to a structural form in which it can be put into a
DBMS, and then the database takes on physical existence. In this system a database
server is connected with the application server to store all the events data that
generated by the devices of the vehicles.
When a user login to the system the user has some privileges to access control over
the system resources and it is defined in the ACL (Access Control Logic). So how
entities interact with in the system depend on the permission given to access control
over the entities (or resources). The role, waypoints, devices, geozones and other
components as configured in the user account are treated as functional components.
These functional components are considered as entities of the system. The main
interacting entities and their relationships are defined in the following ER diagram.
ER diagram of the AFMS system (Fig-18)

28
4.4 Database Schema

There are 24 tables are used in this system Following are the information of Database
schema of the tables defined within the AFMS. All the tables are generated by
Netbeans 6.5 IDE. Tables name attributes, and the main constraints of the tables are
listed below:
1. Account:
This table defines the top level Account specific information. Account table stores all
accounts related information as created by this system.
accountID (primary key)

accountType
notifyEmail
speedUnits
distanceUnits
volumeUnits
economyUnits
temperatureUnits
privateLabelName
expirationTime
password
contactName
contactPhone
contactEmail
timeZone
passwdQueryTime
lastLoginTime
isActive
displayName
description
notes
lastUpdateTime
creationTime
defaultUser
newUserRoleID
lastUpdateUser
balanceSMS
balanceLoginPerDayPerUser
balanceUser
maxDevices
address
street
city
country
pin
29
2. AccountString:
This table defines Account specific customized String key/values.
accountID (primary key) (foreign key)

stringID (primary key)
singularTitle
pluralTitle
description
lastUpdateTime
creationTime
lastUpdateUser
3. AlarmCondition:
The administrative user interface (UI) would allow defining the possible alarm
conditions in the back end.
alarmConditionID (primary key) (system generated numeric ID)

inputType (possible values: digital, analog, waypoint)
input (e.g. door, window (digital), temperature (analog), null (in the case of
waypoints) etc.)
alarmCondition (e.g. ON, OFF, TOGGLE (digital), <,=,> etc (analog), Entering,
Not Entering, Leaving, Not Leaving (waypoints) etc) - The operator will b
applied right of the analog value.
description
creationTime
4. AlarmRules:
This table stores alarm settings set against a device under a rule of an account. This
gets updated only when a new alarm is set against a rule.

alarmID (primary key)
ruleID (primary key) (foreign key)
alarmConditionID (foreign key)
isMonSelected
isTueSelected
isWedSelected
isThuSelected
isFriSelected
isSatSelected
isSunSelected
startTime
endTime
isActive
description
lastUpdateTime
creationTime
30
lastUpdateUser
5. Device:
This table defines Device/Vehicle specific information for an Account. A 'Device'
record typically represents something that is being 'tracked', such as a Vehicle.

deviceID (primary key)
groupID
equipmentType
apnUserID
uniqueID
simPhoneNumber
imeiNumber
isActive
displayName
description
lastUpdateTime
creationTime
lastUpdateUser
gpsNotVisibleCounter-> rename to gpsUnavailableDuration
gpsNotVisibleTimeStamp ->rename to gpsUnavailableTimestamp
devicePlanID
balanceHistory-> rename to 'history' -> this would contain how many days of
historical data that would be stored for the device
balanceWayPoint -> not required
balanceAlarmRules -> not required (instead add the following two fields):
balanceReport -> contains the number of reports that can be generated for the
device
geocoderMode -> this field is updated with the value of geocoderMode under
deviceTariffPlan
geofenceID
isGeofenceEntering
contact1
contact2
simServiceProvider
apnPassword
devPassword
(Whenever a gps not visible packet is received, it will check the time stamp of the last
eventData entry and compare it with the time stamp of the last GPSNotVisible entry. If
the
former
is
greater,
counter
is
reset
else
incremented.)
31
6. DeviceGroup:
This table defines Account specific Device Groups.

groupID (primary key)
displayName
description
notes
lastUpdateTime
creationTime
lastUpdateUser
7. DeviceList:
This table defines the membership of a given Device within a DeviceGroup. A Device
may be
defined in more than one DeviceGroup.

groupID (primary key) (foreign key)
deviceID (primary key) (foreign key)
lastUpdateTime
creationTime
description
lastUpdateUser
8. DeviceRuleMap:
This table defines Device specific Rules.

creationTime
lastUpdateUser
9. EventData:
This table contains events which have been generated by all client devices.
accountID (primary key)

deviceID (primary key)
timestamp (primary key)
statusCode (primary key)
eventSequence
motionStatus =>values as defined in the status code logic. No further logic
needs to be implemented to identify start etc.
isIgnitionOn
32
latitude
longitude
speedKPH
heading
altitude
address
remoteAddress
rawData
distanceKM
odometerKM
creationTime
duration => the differential increment in time from the previous record for a
particular device (timestamp:duration = odometer:distance)
10. GeneratedAlarm:
eventSequence (foreign key references EventData table)

alarmString
ruleID (foreign key)
alarmID (foreign key)
isActive (a notification which has been checked by the user would not be
displayed)
creationTime
The rule engine will go through the status code sent by the device and it will store a
record in this table if the status meets a system generated alarm (e.g. SOS) or if any
of the alarm conditionsfrom a defined ruleID/AlarmID is met.
11. Geofence:
This table defines Account specific geofences.

geofenceID (primary key)
latitudeNE
longitudeNE
latitudeSW
longitudeSW
displayName
description
lastUpdateTime
creationTime
lastUpdateUser
33
12. Geozone is required to define a radius of a particular area. It will display a

circular area to alert vehicles in this region.
This table defines `Geozone`
AccountID (Primary Key)

GeozoneID (Primary Key)
SortID (Primary Key)
MinLatitude
MaxLatitude
MinLongitude
MaxLongitude
ZoneType
RadiusMeters
Latitude1
Longitude1
Latitude2
Longitude2
Latitude3
Longitude3
Latitude4
Longitude4
Latitude5
Longitude5
Latitude6
Longitude6
ClientUpload
ClientID
Reversegeocode
ArrivalZone
DepartureZone
StreetAddress
City
State/Province
PostalCode
Country
Subdivision
DisplayName
Description
LastUpdate
CreationTime
34
13. GroupList:
This table defines the membership of a given User within a DeviceGroup. A Device
may be defined in more than one DeviceGroup.

userID (primary key) (foreign key)
groupID (primary key) (foreign key)
creationTime
description
lastUpdateTime
lastUpdateUser
14. Notification:
This table defines notification options set against each user.

isSMSNotification
isEmailNotification
lastUpdateTime
15. PendingPacket:
This table contains configuration packets which are to be sent to the client device the
next time it 'checks-in' with the server.
packetSequenceNo (primary key)

accountID
deviceID
sendTime (the time stamp when command is entered into the outgoing
command queue)
packetData -> (the actual command being sent to the device)
isSentPacket
packetCode (possible values: set geofence, unlock door, lock door, engine
immobilize, engine release, etc - a list needs to be created for all possible
values)
senderID (possible values: UserID, effiKC)
Note: For generating outgoing command report, the report engine would fetch the
deviceID, senderID, sendTime and packetCode for displaying in the report under
transmit mode= GPRS
35
16. Resource:
This table defines Account specific text resources.

resourceID (primary key)
title
type
properties
value
displayName
description
lastUpdateTime
creationTime
lastUpdateUser
17. Role:
This table defines Account specific Roles.

roleID (primary key)
displayName
description
notes
lastUpdateTime
creationTime
lastUpdateUser
18. RoleAcl:
This table defines Role specific Access Control permissions.

roleID (primary key) (foreign key)
aclID (primary key)
accessLevel
description
lastUpdateTime
creationTime
lastUpdateUser
36
19. Rule:
This table stores the mapping of account and rule ( 1:N). This gets updated as soon
as a new rule is created in an account.

ruleID (primary key)
creationTime
lastUpdateUser
lastUpdateTime
description
20. SystemProps:
This table defines system-wide installation property key/values.
propertyID (primary key)

value
description
lastUpdateTime
creationTime
lastUpdateUser
21. User:
This table defines Account specific Users.

userID (primary key)
userType
password
gender
contactName
contactPhone
contactEmail
timeZone
passwdQueryTime
lastLoginTime
isActive
displayName
description
notes
lastUpdateTime
creationTime
firstLoginPageID
roleID
preferredDeviceID
lastUpdateUser
37
22. UserAcl:
This table defines User specific Access Control permissions.

aclID (primary key)
accessLevel
description
lastUpdateTime
creationTime
lastUpdateUser
23. WayPoint:
This table defines Account specific waypoints.
waypointNumericID (primary key) (system generated unique ID per account)

accountID (foreign key)
waypointID (foreign key)
centerLatitude
centerLongitude
description
lastUpdateTime
creationTime
lastUpdateUser
24. OutgoingSMS
smsSequenceNo (primary key)

accountID
receiverType (possible values: device, user)
recipientID (possible values: deviceID, userID)
receiverNumber (mobile number of the receiver)
sendTime (time stamp when message is entered into the outgoing SMS queue)
senderID (possible values: userID, sanat)
packetCode (text:possible values: set geofence, unlock door, lock door, engine
immobilize, engine release, etc -check packet code list)
packetData (text: the actual text message to be sent -> updated by
OutgoingMessageMonitor engine)
38
4.5 Use Case Diagram of the system

Use case diagram of UML used for modeling the dynamic aspects of the system. Use
case diagrams are used for visualizing, documenting, and specifying mainly the
behavior of the components interacting in the system. It is also important for testing
executable systems through forward engineering and to understand the executable
systems through reverse engineering. In this system, the behavior of different
interacting components is expressed in the following use case diagrams.
The below use case diagram (Fig-19) shows interaction of the users access control
logic or account owners with the system.
39
40
Fig-20
The above use case diagram shows administrators behavior with the system. That is
how an administrator can create an account, giving privileges to the account holder,
permission password change, manage waypoint etc.
41
The below use case diagram shows how communication server or application server
behaves with the system. That is how communication server configures the devices,
setting alarm, etc.
Fig-21
42
4.6 Algorithm embedded in this model

In this Automatic Fleet Management System, all vehicles are tracked and controlled
remotely by the user application program. One of the vehicles may have some
problem i.e. is in break down state. Now passengers have to rescue to reach their
destination. So the fleet management system has to provide better solution to reach
the passengers to their destination. This thesis work contributes this part in the AFMS
to represents how the distressed passengers can be reached to their destination with
minimum hop that is passengers can reach to their destination with minimum vehicle
changes. This approach has many folds return to the passengers it is less hazardous,
time consuming and cost effective solution.
Dispatching a nearest vehicle of the route to breakdown vehicles may be the best
choice. But in the summary of Literature survey [2.4] I have pointed out it may not be
the best choice. The following algorithm may be a better choice to reach the
passengers to their destination with minimum cost and hence time.
Starting node
Destination node
Fig-21(a)
The above graph G, states that the breakdown vehicle is at the starting node a and
have to reach the destination node m. The core concept of this algorithm is that
each node is associated with a data structure given below:
43
Structure node :
Status : Boolean // either visited or not
Buslist : List
// List of buses in the route
Weight : integer // length of the route between nodes
sp
: stack // for push pop operation
q
: queue // to enqueue elements of the graph
Hopcount: integer // to count the number of hops
1. Initially make the source code permanent and make it as a current working
node. All other nodes marked as temporary.
2. Examine all the temporary adjacent nodes of the current working node and
after checking the condition minimum hop distance, relabeled the required
nodes.
3. From all temporary nodes, find the node which has minimum hop distance. If
more than one node have same hop number then check their minimum
distance and mark this node permanent and this is the current working node.
4. Repeat step 2 and 3 until destination node is made permanent.
Pseudo code of this algorithm is as follows:

The graph G = ( V,E ) has all nonnegative nodes and each node is associated with
the above mentioned data structure. For simplicity this graph can be thought of as
a directed graph i.e. vehicles are routed in a particular direction. All notations used
in this algorithm are as a general convention of data structure.
MinHopAlgo (G, W, BL, s)
/* G is the graph i.e. is road layout, W is the weight or length of the path, BL is the
bus list of the routes, and s is the starting node */
1. Initialize-Graph-Source( G, s)
2. S0
3. QV[G]
4. while Q != null
5. do uFind-MinHop(Q)
6. SS U { u }
7. for each vertex v Adj[u]
8. do Relax(u,v,bl,w)
44
Initialize-Graph-Source( G, s)
1. for each vertex v V[G]
2. do d[v] 0
3. d[s] 0
4. [v] nil
5. BLnil
6. stacktop null
7. queuefront=queuerearnull
8. Hopcount0
Relax(u,v,bl,w)
1. size0
2. for all u == s
3.
do BL[v] Bl[v] U BL[u]
4. else
5. BL[v] Bl[v] BL[u]
6. sizelength(BL[v])
7.
if size >0 and stacktop ==null
8.
= w (u,v )
9.
push ( )
10.
[v] u
11.
else
12.
if size > 0 and stacktop != null
13.
= w (u,v )
14.
pop()
15.
if >
16.
then [v] u
17.
else
18.
++Hopcount
19.
= w ( u, v )
20.
if Queue == null
21.
Enqueue [ ] and [v] u
22.
else
23.
Dequeue()
24.
if <
25.
then [v] u
45
Chapter 5
Implementation Details
5.1
Introduction
Automatic Fleet Management System is implemented with the following

components:
Mobile Units (MU) or in-vehicle equipment (VTU)
Fleet management server at the control station (CS)
Web based User terminal
Implementation diagram of AFMS (Fig-22)
The above figure states that the Control Station and Mobile Unites are communicated
through the GSM network. A Fleet Management System comprises of a control
station that gathers location information from a fleet of vehicles each fitted with invehicle equipment. The in-vehicle equipment comprises of a position sensor and a
communication device. GPS is a clear choice for the position sensor as it provides 24hour accurate three-dimensional location, velocity and time information for users
46
anywhere on or near the surface of the Earth and is free of service charge. The
location information from the vehicle can be relayed back to the control station by
means of several RF media. GSM is an optimal choice considering flexibility,
performance, security and cost. Also GSM is the widely used wireless communication
standard available in most parts of India. Web based user terminal provides graphical
map of the route layout with a good communication with the control station.
5.2 Software components

To view the current position of the device a web-based application has been
developed. Using this Web application an end user will be able to view the live
position of the vehicles and also the past position by selecting a specific date and
time interval. To develop this system the following soft wares are used:

Java (JDK1.6 with Net Beans 6.5 version IDE tools ) ,

JavaScript and Ajax scripting language
MySQL database server with Navicate Lite tools
Apache Tomcat 5.5.28
Google Map
JDK1.6 with NetBeans 6.5 version IDE tools are used to built the web application
file (track.war file).
MySQL database server is used for storing data because of its high-performance
query engine, tremendously fast data insert capability, and strong support for
specialized web functions like fast full text searches [1]. A case study shows that it
could process an average of 3000 queries per second [2].
Apache Tomcat used as a web server to provide the web application with internet.
Google Map is used as a map provider to the web browser to track the fleets
physical location in GUI based platform. To buildup this system there are 26
packages are used. Packages are listed below:
org.opengts,
org.opengts.db,
org.opengts.db.dmtp,
org.opengts.db.tables,
org.opengts.dbtools ( Contains tools for accessing SQL databases Currently MySQL
and
Microsoft
SQL
Server
are
supported.
),
org.opengts.dbtypes,
org.opengts.geocoder, rg.opengts.geocoder.geonames, org.opengts.servers.gtsdmtp,
org.opengts.servers.template, org.opengts.tools, org.opengts.util (Contains various
common use utilities that make programming a little easier), org.opengts.war.events ,
org.opengts.war.gc101, org.opengts.war.gprmc, org.opengts.war.maps, org.opengt
s.war.maps.jsmap, org.opengts.war.mologogo,
org.opengts.war.report,
org.opengts.war.report.dmtp,org.opengts.war.report.event,
org.opengts.war.report.field,
org.opengts.war.tools, org.opengts.war.track, org.opengts.war.track.page, org.open
gts.war.track.taglib,
In these 26 packages total number of classes is 321

47
5.3 Hardware components

In-Vehicle Equipment (Mobile Unit)
GPS Receiver
GSM modem
The main feature of GPS receiver is its low cost, small form factor, and higher
sensitivity. These advantages along with its lower power consumption make it ideal
for vehicle tracking applications. Both the hardware units are embedded in the Vehicle
Tracking Unit (VTU).
Application Server with GSM modem
Database Server
Laptop / desktop ( for user interface )
5.4 Protocol used for communication

5.4.1 GPS Protocol
In this system National Marine Electronics Association. (NMEA) 0183, version 2.0
protocol is used for GPS connection and in Fig-05 explains how application server
accepts data using this protocol. NMEA is a standard protocol, used by GPS receivers
to transmit data.
5.4.2 HTTP Protocol

HTTP protocol is used for Application server and for user interface in web based
applications.
5.5
Detail description of the Implementation
The In-vehicle tracking unit VTU consists of a GPS receiver and a SIM. The SIM is
attached to VTU to make it enable of working in GSM network around the world.
Before to place it in a vehicle its functional activities
should be properly set to
initialize the network system. The VTU accepts GPS satellite raw data and send it to
the application server through GPRS/GSM technology and finally store it in a
database server in a human readable data format. The following flow diagram shows
the overall system implementation step-by-step:
48
After VTU is switched ON
Network is
Initialized ?
Wait
Get IMEI number
Get GPS data

NO
Retry to
connect
Yes
NO
Connect to
GPRS ?
Connect to Appl
server?
Store
Data in
Database
Server
Connection to Appl server

Yes
No
Disconnect from Server
Fig-23
Wait
Yes
The below diagram shows the function of Application server. It accepts the raw
positional data which is then converted it to a human readable form using Reverse
Geocoding technique. Actually a java file named EventDataProvider.java is
responsible for accepting the raw data which is sent by the GPS modem via GPRS
using POST method of the HTTP protocol, this data consists of IMEI number of the
device, Latitude, Longitude, Date, Speed and number of satellite. IMEI number is
used to authenticate the device. Now this raw data is converted and finally stored into
database. The term geocoding generally refers to translating a human-readable
49
address into a point on the map. The process of doing the converse, translating a
point into a human-readable address, is known as reverse geocoding. The
GClientGeocoder.getLocations() method supports both standard and reverse
geocoding. If we pass this method a GLatLng object instead of a String address, the
geocoder will perform a reverse lookup and return a structured JSON object of the
closest addressable location. Actually the closest addressable location may be some
distance from the original latitude and longitude values of the query, if the supplied
GLatLng is not an exact match for any addressable locations.
Listen to Accept new

Position
New Position
Is it a valid
IMEI NO.?
Yes
Convert NMEA Raw
data to Decimal Format
Decimal Lat and Lon
Find the nearest

Location using Reverse
Geocode
Position with Name
Save data to Database

Server
Application server functional flow diagram (Fig-24)
50
Now the question is how to find the Nearest Location?

The Spherical law of cosines is used to find out the name of the vehicles location.
This formula is used generally for computing great-circle distances between two pairs
of coordinates on a sphere. Spherical law of cosines [3]:
d=R*acos(cos(lat1).cos(lat2).cos(lng2lng1)+sin(lat1).sin(lat2))
Here, d is the distance between two coordinates (lat1,lng2) and and (lat2, lng2).
Below is a geocode table and is implemented which has four attributes as given in
Table 1.
Table 1 Geocode Table
ID
Name of the Place
Latitude
Longitude
AQ Block, Bidhannagar, Kolkata,

West Bengal, India
ED Block, Bidhannagar, Kolkata,
West Bengal, India
Bidhannagar, Kolkata, West Bengal,
India
Maniktala Main Rd, Kankurgachi,
Kolkata, West Bengal, India
Acharya Prafulla Chandra Rd,
Kolkata, West Bengal, India
22.5777233333333
88.4395816666667
22.5825366666667
88.4239583333333
22.5816516666667
88.429505
22.583765
88.3789983333333
22.5833383333333
88.3746916666667
2
3
4
5
After receiving a new position, the nearest location name of the newly received
position is found. This is done by running the Spherical law of cosines in the following
sql query:
"SELECT name, ( 3959 * acos( cos( radians('lat1) ) * cos(
radians( lat2 ) ) * cos( radians( lng2 ) radians('lng1') ) + sin(
radians('lat1') ) * sin( radians( lat2 ) ) ) ) AS distance
FROM geocode
HAVING distance < 5
ORDER BY distance LIMIT 0 , 1"
This query returns the name of the location which has the shortest distance with the
new position.
How Live Tracking is being done?

Live tracking is the major part of this web application. This enables a user to view the
live position of the vehicle(s) on the map. Google Map Satellite version as defined in
the private.xml is used to locate the position. After Logging in, a user will
automatically be redirected to live_track.war file.
51
Live tracking as a sample of vehicle Red i-10 movements with different seed and
direction has been shown near Bidhannagar, as land mark.
Movement of a vehicle with different seed (Fig-25)
52
5.6 Evaluating the Performance Benefits of the Automatic Fleet Management

System
There was little a evidence from the survey results that many or any AVL systems had
been the subject of rigorous (i.e. quantified) evaluation. So the primary motivation for
this technology is to provide reliable, real time on-line functionality. Practically shown
that if the number of vehicles increases the AFMS system can provide better services
and hence the performance graph also elevated and the below figure shows this
report.
10
12
14
16
hours
Normal fleet system
AFMS
P/H means passengers/hour
Performance graph of vehicles (Fig-26)
53
18
20
User Interface - main menu performance improvement

It is Suggested that put the time stamp and motion status in Device table. (so that for
fetching last time stamp and motion status we don't have to scan EventData table as
well as device table)
PERFORMANCE CHECKING:checking with 300 clients:start time(mili sec):1242991465303
end time:(mili sec) 1242991468352
{while fetching data from EventData data table. }
total time difference:(mili sec) 3049
start time(mili sec):124299161374
end time:(mili sec)124299164007
{while fetching data from Device table.}
(performance inprovement around 15.7%)
checking with 500 clients:start time(mili sec):1243056149896
{time taken to load the page with data and showing them in the UI by fetching data
from EventData table}
{time taken to load the page with data and showing them in the UI by fetching data
from Device table}
(performance inprovement around 17%)
54
PERFORMANCE CHECKING :
with 300 client:
{fetching data directly from the Device table}
{fetching data directly from the EventData table having 1250 rows}
(performance inprovement around 7.1 %)
with 500 client:
{fetching data directly from the Device table}
{fetching data directly from the EventData table having 1250 rows}
(performance inprovement around 8%)
55
Chapter 6 System simulation

6.1 Overview
Simulation of the overall thesis works main parts are systematically shown in the
following context. At first the simulation part shows the inside core concepts of this
system.
Satellite
GPS connection
GPRS
System
PortNo 31200
Socket connection
SIM
GPRS connection
VTU
(In-vehicle electronic component)
GPRS Modem
Application /
Communication
Server
Internet
Application running
User Interface
Fig-27
Database Server
56
6.2
Flow Diagram
This simulation diagram depicts the main activities of this thesis work.
Application / Communication server receives

the raw data: GPRS format data
Then Communication server confirm the

correctness of received data by checksum
method
Communication server then parse the data
Extract the
data/String
different
segments
of
Then send to the EventData mainly to the

database server
Now authorized users can connect to the

Web/Application server to use the AFMS
system
Fig-28
57
the
6.3 Some execution snapshots of this system

Now the following diagrams show when a user explores the different
functionalities of this AFMS system
Contents of the simulation:
1) Introduction
2) Login
3) Main Menu
4) Mapping
4.1) Vehicle Map
4.2) Group Map
5) Summary Reports Last Known Location Summary
6.1) Account Admin
6.2) User Admin
6.3) Vehicle Admin
6.4) Group Admin
6.5) Geozone Admin
6.6) Change Password
1) Introduction
This simulation chapter shows each step of thesis works stating from the initial login
to the various capabilities of the AFMS system. It includes Mapping, Reporting and
Administrative capabilities of this system. The intention of this simulation part is to
follow a step-by-step understanding of the core concept of this thesis by providing
some visual outputs. After installing and configuring all components of this system the
following steps will occur :
2) Login
The AFMS login window allows to login as a user or as an administrator. When login
as a normal user input data to the three text fields account, user name and password.
Here the user is under an administrator account so he/she has to mention the account
string of the administrator. But to enter as an administrator input only the account and
password filed of the administrator. The below fig-27 shows this activity.
58
Login screen of the system Fig-29
3) Main Menu
After login to the system user can access the main navigation menu, shown on the next
page (Fig-28). The functions of the system are broken down into 3 main categories:
Mapping, Reports and Administration. Each of the tabs corresponds to the appropriately
named category of functions. Navigation may be done in one of two ways:
Either from the Main tab, select Main Menu and the screen displayed above will be
presented. From there, we can select whichever section of the application is of our interest.
Or , we can use the individual tabs (Mapping, Reports, Administration) to select
functions within those specific categories. For instance, from the Reports tab, we may select
Vehicle Detail Reports, Vehicle Summary Reports, or Driver Performance Reports.
59
Main menu screen (Fig-30)
4) Mapping
4.1) Vehicle Map
Now we get to start with the Mapping functionality. Now after clicking on the link Track
Vehicle Locations on a Map as highlighted above.The following screen will be displayed after
selecting the appropriate vehicle (here Redi-10 is selected as a vehicle) and date range.
Vehicles are moving in different speed and accordingly it is coloured.
60
Vehicle Map screen (Fig-31)
4.2) Vehicle Group Map

In the previous map control has been on the individual vehicle mapping. Lets look at what
can be done in terms of mapping group devices. From the Mapping tab, select Vehicle Group
Map to display all the vehicles in a given group or the entire fleet. Depending on the manner
in which vehicles are grouped within the fleet system, it is possible to look at either an
individual group of vehicles or the entire fleet on the map. In this system the Vehicle Group
61
Map will display the entire fleet of vehicles. This is equivalent to a Vehicle Group which is the
same as the entire fleet. Vehicles Group map displayed in the below screen.
Group Vehicle Map screen (Fig-32)
5) Summary Reports
Device Detail Reports, Fleet Summary Reports are focused on either a group of vehicles or
an entire fleet. These are not relevant to a specific vehicle, as they present such information
that is only useful when viewed across a group of vehicles or assets. The GPS Tracking
Reports Fleet Summary Reports Screen can be accessed from the Reports tab and
appears as shown below. The summary report can display in HTML format or in text format.
62
Summary report screen (Fig-33)
6) Administration
6.1) Account Admin
By selecting Account Admin from the Administration tab, the Edit Account Information
screen will be displayed, as shown below. After making any changes in this screen, it
is important to press the Change button at the bottom of the screen to save those
edits (a message should then be displayed at the bottom of the frame to confirm that
the information was saved). To cancel changes, press the Cancel link.
63
Account Admin screen (Fig-34)
6.2) User Admin

By selecting User Admin from the Administration tab, the View/Edit User Information
screen will be displayed, as shown in Fig-29below. On this screen, we can watch all
of the defined users in the system. There are a number of fields that are available in
this summary view -- User ID, User Name, Contact Name, Contact Email, Time Zone
and whether the user is Active (i.e. allowed to log-in). As we can see from the list
below, it isn't necessary to populate all of these fields when setting up new users to
the system.
64
View/Edit User Information screen (Fig-35)
Similarly this system can see Vehicle Admin, Group Admin, Geozone Admin, and
Change Password. By selecting Geozone Admin from the Administration menu, the
View/Edit Geozone Information screen will be displayed. To see the Geozone we need
to define the radius for the Geozone and it will display a circular area to alert vehicles in this
region.
6.5) Geozone Admin

One of the most powerful administrative tools is the Geozone Admin function. It is a
circular area. A Geozone can be defined around any reference location on the map.
Definition is simple and once completed, movement of vehicles in and out of that
Geozone will populate the Event Detail report with the specific description of the
Geozone which would use a custom reverse geocoded address. By selecting
Geozone Admin from the Administration menu, the View/Edit Geozone Information
screen will be displayed, as shown below
65
Geozone area on map (Fig-36)
66
Conclusion
This thesis has presented a survey of automatic vehicle tracking along with its
security, reliability, low cost technology usage. As an emerging field of technology,
automatic vehicle tracking has many unresolved issues associated with it besides its
potential. This thesis has tried to discuss both the potential aspects and concerns
regarding automatic vehicle tracking side by side. Thus, this thesis provides the
opportunity to have in depth knowledge of different aspects of automatic vehicle
tracking system. Vehicle tracking system has made such a model that manages a
company's vehicle fleet mainly concern with the vehicle telemetric.Tracking and
monitoring the entire fleets movements is controlled by the GPS system. GPS is a
satellite-based navigation system that works by receiving positional data from
satellites and calculating locations. It is the most effective solution in terms of cost and
real time basis data collection. This thesis has discussed different types of
technologies its challenges and performance overheads. Besides this, some case
studies are also given which have provided the implementation details of virtualization
by different vendors. These case studies also describe how different vendors have
addressed the challenges regarding the virtualization through their specific
implementations. There are certain security concerns, which open new challenges for
the user as well as service provider and which do not exist in the case of traditional
communication system, have been discussed in this thesis. This thesis has discussed
the role of trust, privacy and security in the healthy development of vehicle tracking paradigm.
This thesis has tried to encompass most of the reliability issues regarding tracking of the
fleets, their challenges and some case studies which have effectively tried to address those
challenges. This thesis has discussed the pros and cons of tools and techniques of satellite
and mobile communication with n-tier web based system presently available to address the
vehicle tracking system.
67
APPENDIX
Push technology is a set of technologies used to send information to a client

without the client requesting it
Push versus Pull
Pull technology is based on the traditional request/reply model. It
requires that users know a priori where and when to look for data. It
suffers from transmission latency and duplicate data traffic.
Push technology allows users to get information as soon as it become
available and users do not have any knowledge about virtual information
servers. This transfer of control from users to providers is a potential
problem.
Push technology can automatically deliver key management decision-making
information via e-mail, printers, fax machines, pagers, PDAs, and other
communication devices.
Telematics: It is an emerging technology that is of interest because these solutions

combine the functionality of internal vehicle electronics, wireless communications, and
information technologies, such as internet and GPS, for the delivery of information,
services, communications and applications. Telematic services include emergency
roadside assistance, mileage records, vehicle location tracking, automatic accident
notification, remote equipment diagnostics, remote fuel management, email, text
messaging, application access, video conferencing, and telephone. Second
generation of telematics, which focus on predictive and preventive maintenance by
allowing the telematic device to transfer system codes from the vehicles computer to a
database.
GPS (Global Positioning System) car navigation systems can show and even tell you
how to get to any destination. Instead of having to bother with cumbersome maps that
can never seem to be updated or refolded correctly, travelers can rely on Global
Positioning Systems (GPS) to find their way around the world. GPS devices are able
to give you accurate information about your location and directions to your destination,
as well as the time. A Geographic Positioning System (GPS) receiver is a hardware
device that uses satellites to determine your physical location and to display it on a
screen. With a GPS and a set of waypoints, you can navigate in unfamiliar wilderness
territory or quickly discover the fastest way to reach an address in a city. A waypoint
is a physical location in space expressed on a GPS as a standard set of coordinates
(two for land and three for air or space). A route is a navigated line between one or
more waypoints such as between a starting point and ending destination.
68
GPS satellite (picture collected from http://www.ehow.com/facts_5005974_whatwaypoint-gps.html ) Fig-37
GPS needs a clear line of sight to the sky to calculate waypoints correctly. You can
enter and display waypoints as a latitude and longitude (i.e. 4044 25N 7400 25W)
or more usefully as an address (335 Melody Lane, New York, New York). On a GPS,
a waypoint is typically identified and indexed with a familiar name such as "Mom's
House" or "Demand Studios." o make them easier to understand, waypoints are often
displayed as points on a map. This is especially helpful when visualizing a route or
trying to find the closest destination to your current location. Though a GPS can store
waypoints simply for reference, they are most often used to calculate the shortest or
fastest route between a user's current location and his intended destination. The
Google Maps site offers way an easy way to create and manage waypoints through
the use of a keyboard and mouse. However, its coordinate system needs to be
converted to GPX format, the default for GPS units. Use GMapToGPX to transfer
from Google to GPS, and GPS Visualize to transfer from GPS to Google (see
Resources).
When people talk about "a GPS," they usually mean a GPS receiver. The Global
Positioning System (GPS) is actually a constellation of 27 Earth-orbiting satellites
(24 in operation and three extras in case one fails). The U.S. military developed and
implemented this satellite network as a military navigation system, but soon opened it
up to everybody else.
69
Each of these 3,000- to 4,000-pound solar-powered satellites circles the globe at

about 12,000 miles (19,300 km), making two complete rotations every day. The orbits
are arranged so that at any time, anywhere on Earth, there are at least four satellites
"visible" in the sky.
A GPS receiver's job is to locate four or more of these satellites, figure out the
distance to each, and use this information to deduce its own location. This operation
is based on a simple mathematical principle called trilateration. Trilateration in threedimensional space can be a little tricky, so we'll start with an explanation of simple
two-dimensional trilateration.
How accurate are GPS receivers, and what affects the accuracy?
The atmosphere, the ionosphere and the position of your receiver could all affect the
GPS accuracy. Also buildings or heavy foliage that obstructs the GPS view (line of
sight) of the sky may decrease the position accuracy. GPS provides two levels of
service -- a Standard Positioning Service (SPS) for general public use and an
encoded Precise Positioning Service (PPS) primarily intended for use by the
Department of Defense. SPS signal accuracy is intentionally degraded to protect U.S.
national security interests. This process, called Selective Availability (SA), controls the
availability of the system's full capabilities. The SPS accuracy specifications, given
below, include the effects of SA.
SPS provides accuracy's of (for position, the accuracy with respect to geographic, or
geodetic coordinates of the Earth) within: 100 meters (2 drms) horizontal 156 meters
(2 Sigma) vertical 300 meters (99.99% prob.) horizontal 340 nanoseconds time (95%
prob.) SPS Coverage is continuous and worldwide, with a position dilution of precision
(PDOP) of 6 or less. However, Selective Availability (SA) was switched off on May
2nd,2000.
70
Appendix B
Comparative study between GPRS/ICS Based System and SMS Based System
In any vehicle tracking system, the communications infrastructure is crucial. This is
because it is this that brings information back to central control. The GSM
infrastructure and in particular the GPRS/ICS (Generalized Packet Radio Service /
Internet Communications Services) function of GSM. This function allows mobile
phone users to send Multimedia Messages (MMS) and to surf the Internet. This mode
of communications because it gives the best priced versus communications speed
and availability to the fleet managers.
1.
2.
GPRS/ICS Based System

(Starfish)
Streams location data back
periodically and when special
events occur.
Approximate cost only Rs.5.0
for 10240 characters of data.
3.
A permanent virtual 48K bits

per second link ensures
immediate data transfer.
4.
No limit on the amount of data

that can be transferred.
5.
Data streaming means data is

already available in the control
centers database when it is
required.
When the vehicle is parked in
the basement of a building and
GPS and/or GSM signals are
no longer available, the last
point outside the building is
available because of data
streaming. The system will
know that it is in a particular
building.
6.
SMS Based System

Location data is only sent back on
demand. Special events may trigger
a SMS message back to central.
Approximate cost 50 Paisa
Rs.2.50 for a packet of 180
characters of data.
Latency of varying periods for a
packet of data to be transmitted
dependant on the GSM system
load. Typically 15 seconds.
Limited to 180 characters per
packet. Longer data messages must
be broken into multiple SMS
messages.
A SMS must be sent to one or all
vehicles and their response is
required before their location is
known.
When the vehicle is parked in the
basement of a building and GPS
and/or GSM signals are no longer
available, any SMS sent to request
for location would get a negative
response or no response at all. The
vehicle is effectively lost.
Point 6 is a significant reason why SMS based systems are not suitable for Fleet
Management, particularly when the fleet is concentrated in major cities where
vehicles are parked mainly in basement car parks.
71
How to calculate the number of entering and leaving passengers through

a door of a vehicle?
The method which is used at calculation of number of entering and leaving
passengers through a door of a vehicle is based on use of tiny gauges of thermal
radiation which are mounted above doors of a vehicle .Gauges register impulses of
thermal radiation which each time arises at crossing by the passenger of a zone of
measurement of the gauge of the analyzer. The gauge includes passive and active
elements. The active component in the gauge consists of the transmitter. Data
obtained from routes collect in constant databases of volumes of passenger traffic,
in the further are processed by applied software in the cuts necessary for motorvehicle pools and city administration.
JSON (stands for JavaScript Object Notation) is a lightweight text-based open
standard designed for human readable data interchange. It is derived from the java
scripting programming language for representing simple data structures and arrays,
called objects. Despite its relationship to JavaScript, it is language-independent, with
parsers available for virtually every programming language.
How to get the current epoch time from human readable date?
1 Second = 1 in Epoch
1 Minute = 60 in Epoch
The following java program gives the output of epoch value from human readable
date format.
import java.util.Calendar;
import java.text.SimpleDateFormat;
public class GetEpochTimeWindows {
public static void main(String arg[]) {
try{
// Getting the current epoch time
long epoch = System.currentTimeMillis()/1000;
System.out.println("Epoch time =>"+ epoch);
// Convert from Readable date to epoch
System.out.println("Parsed date=>"+
new SimpleDateFormat ("dd/MM/yyyy HH:mm:ss").parse("01/01/1601 00:00:00"));
}catch(Exception e){
System.out.println(e.getMessage());
}
}
}
Convert from human readable date to epoch format:
long epoch = new java.text.SimpleDateFormat ("dd/MM/yyyy
HH:mm:ss").parse("01/01/1970 01:00:00");
72
Appendix C
Super Admin:
The developer/ owner of the software with all privileges. They can create, delete
accounts with expiration times etc.
Account:
Owner of the account (usually the transport head of an organization).
He has overall privileges (ACLs) of administering his account except for changing
account ID, expiration date, contact info, service agreement and billing information.
User:
An account owner can create several users for the account. The administrative
privileges (ACLs) for the user are determined by the account owner, either by
assigning a role to the user or directly modifying the permissions (ACLs) of the user to
various functionalities in the application.
A user cant however change his user id and contact information, which can only be
set by the account owner.
A user id is unique for an account but can be same across different accounts.
Among the various permissions given to the user, permissions to view/edit devices
are a critical one. The way a user is given permission to a device is through a device
group. A user can be assigned one and only one device group and he has
permissions (ACLs) to view or edit all the devices under that device group (?)
Device:
It is the vehicle tracking hardware and is used to represent the car/ vehicle to which it
is attached.
A new device can be added (mandatory fields- device ID and device unique ID; the
unique ID would be created from the IMEI number by prefixing the device type) to the
account by the owner or a user with suitable privileges (ACL). -> for the time being.
An existing device can be edited but the device ID and unique ID cannot be changed
once it has been created.
A device unique ID has to be unique across all devices under all accounts (?). A
device ID needs to be unique across all devices under the same account
73
Device Group:
This represents a functional grouping of various devices under an account. If no
group is defined for the account, the default group is all.
A group can be created by the account owner or a user (based on their ACLs). Group
ID has to be unique for a particular account and cannot be changed once created.
Each device is related by a many to many relationship to a device group as
determined by the account owner or user with suitable ACLs i.e. a device group can
have many devices and some of thee devices of one group may also be a part of
other device groups.
NOTE: Apart from the defined groups, all is also a device group that contains all
devices under that account.
Way Point:
It is also known as a Point of Interest (POI). It is actually a circle defined by its center
and radius.
Several waypoints can be created for an account (by the owner or user with suitable
ACLs).
The waypoint ids need to be unique for that account (and also unique from the
geofence id defined for that account).
Each waypoint is assigned to a vehicle (by a user/ account having write/edit ACL for
that vehicle) by a many to many relationship i.e. a way point can be assigned to one
or many devices and more than one such way point can be assigned to the same
device.
Assignment of a waypoint to a device also implicitly includes the rules for which a way
point violation will be recorded for that device
Geo-fence:
It is a rectangle, defined by the 2 vertices of its SW-NE diagonal.
Each account can have several geo-fences defined for it but each device can have
only one geo-fence assigned to it (a hardware feature)
Alarm Rule:
It would allow the user to create complex rules to generate alarms for various
conditions/values of the inputs (attached to a device)
The user would also be able to define the mode of delivery of the alarm (e.g. email,
sms, and account notification)
Users with proper ACLs can create, edit or view the rules
Users can then assign one or more rules in the account to a device/ group (to which
he has edit ACLs)
The Alarm Rule ID is unique for an account
74
ACL:
An ACL defines the access level for a particular feature or page.
Access levels could be none, read/ view, write/ edit, create/ delete (or all).
The ACL for a feature/ page assigned to a user (or account) determines what that
user (or account) can do with that feature/ page.
Real-time Tracking: Users can watch their vehicles moving in real-time in the online
map. The application should dynamically trace out the route being traversed and also
show valuable information like distance covered and instantaneous speed. The maps
would be automatically updated every time there is new location information in the
database
Geo-Fences: There will be a UI to create a geo-fence, which can then be
uploaded remotely to the hardware. This (hardware) feature will generate
alerts whenever the vehicle enters or leaves the designated geographical area
(as defined by the user)
Way-Points: A UI to define circular areas (point + radius) on maps would be
necessary for this. This feature would allow the user to configure points along
the route that the vehicle must travel to, and receive alerts on arrival and
departure from these points. (This feature can be used to know what part of
the journey and in what time frame has been accomplished by the vehicle or
for example to set up arrival notification if the vehicle is x km away from a
warehouse etc.)
Alarm Settings: There will be a UI to define logic to generate alarms when
certain criteria are met (e.g. if doors are opened, temperature reaches a max
value, vehicle crosses a state boundary, speed exceeds a certain value etc)
Remote Control: Ability to issue commands to the vehicle from the web
interface (e.g. open/ close doors, shut of engine ignition, turn on blinkers/
horns etc)
Geocoding
Geocoding is the process of converting addresses (like "1600 Amphitheatre Parkway,
Mountain View, CA") into geographic coordinates (like latitude 37.423021 and
longitude -122.083739), which you can use to place markers or position the map. The
Google Maps API includes a Geocoding service that can be accessed directly via an
HTTP request or by using a GClientGeocoder object. The Google Maps API provides
a client geocoder for geocoding addresses dynamically from user input.
75
Reverse Geocoding
The term geocoding generally refers to translating a human-readable address into a
point on the map. The process of doing the converse, translating a point into a
human-readable
address,
is
known
as
reverse
geocoding.
The
GClientGeocoder.getLocations() method supports both standard and reverse
geocoding. If you pass this method a GLatLng object instead of a String address, the
geocoder will perform a reverse lookup and return a structured JSON object of the
closest addressable location. Note that the closest addressable location may be some
distance from the original latitude and longitude values of the query, if the supplied
GLatLng is not an exact match for any addressable locations.
Data from Tracker to Call center Sever

$$ + L + ID + 0x9999 + 1B alarm types + GPRMC info + | + HDOP + | +Status(5byte)
+ checksum(2byte) + \r\n
PS: All multi-byte data is based on high-byte first, low-byte back to organize in this
protocol.
Item explain
$$ 2Bytes,indicates header of command from track unit to call center, is
ASCII code(hex is 0x24)
L 1Bytes,indicate length of all command , including header and end(the
array is first high to low).
ID 10Bytes,at best 20 bytes,don`t enough use F to recruit,use hex format.
Eg,ID is 13612345678
So 10 Bytes ID in turn is
0x13,0x61,0x023,0x45,0x67,0x8f,0xff,0xff,0xff,0xff.
when 10 bytes are all 0xff ,it is broadcasting command.
Command data 2Bytes, explain it in command table(just use 0x9999 at present).
DATA the least is 10 Bytes,the most is 100 Bytes.(Detail on Part III: GPRMC Info)
checksum 2Bytes,means CRC check of all data ahead, CRC-16 (Modbus) (initialize
data is 0xffff) checksum , not including itself byte and end character.
\r\n 2Bytes,end char,hex format is 0x0d,0x0a.
Alarm types from tracker to call center server
1B Alarm types:
=0x01 SOS button is pressed
=0x49 2nd button(call B)is pressed
=Ox08 the exterior power was cut off ( 5 minutes intervals)
=0x10 Low battery alarm
=0x30 Trembling for 10S or enable tremble alarm system
=0x40 over speed alarm
=0x41 not over speed alarm from over-speed state
=0x42 out of GEO-fence
=0x43 Into Geo-fence alarm
=0x50 I/O 1 close
=0x51 I/O 1 open
76
=0x52 I/O 2 close

=0x53 I/O 2 open
=0x54 I/O 3 close
=0x55 I/O 3 open
=0x56 I/O 4 close
=0x57 I/O 4 open
=0x88 heartbeat
=0x91 enter sleep mode
=0x92 exit sleep mode
=0x95 GPS Fix
=0xAA Interval GPRS data
GPRMC info
125011.000,A,2232.4587,N,11403.6961,E,58.31,309.62,290708
GPRMC info DATA Format is :
hhmmss.dd,S,xxmm.dddd,<N|S>,yyymm.dddd,<E|W>,s.s,h.h,ddmmyy
Notes:
1. if xxmm.dddd or yyymm.dddd is 0000.000,it means track unit cannot receive
GPS info.
2. List separator | in ASC II is 0x7c
3. HDOP is in ASCII code, HDOP is empty when no GPS signal Parameter
Description Example
hhmmss.dd UTC time, h = hours, mm = minutes, ss =seconds, dd = decimal part of
seconds 13:48:29.486
S Status indicator, A = valid, V = invalid Valid
xxmm.dddd Latitude, xx = degrees, mm =minutes,dddd = decimal part of minutes
11 deg.
<N|S>
Either character N or character S, N =North,
S = South 26.6639 min.yyymm.dddd Longitude, yyy = degrees, mm =minutes,dddd =
decimal part of minutes 111 deg. 33.3299 min.
<E|W>
Either character E or character W, E =East,
W = West West s.s Speed, knots. 58.31 Knots
h.h Heading 309.62 deg.ddmmyy Date, dd = date, mm = month, yy = year 11th, Aug.
2000
77
Reference:
[1] MySQL AB. MySQL Documentation, Available: http://dev.mysql.com/doc/
[2] MySql AB Casestudies. Available: http://www.mysql.com/whymysql/casestudies/
mysql_cs_utel_en.pdf
[3] Movable Type Scripts. Calculate distance, bearing and more between two
Latitude/Longitude points, Available:http://www.movable-type.co.uk/ scripts/
latlong.html
[4] www.cmcltd.com/case_studies/transportation/GPS_System_Case_Study_DTC.pdf
[5] IEEE Xplore - Vehicle Location and Fleet Management Systems
[6] "How GPS Receivers Work" Global Positioning System - Wikipedia, the free
Encyclopedia
[7] GPS Tracking: Open-Source GPS Tracking System - OpenGTS Google Accounts
/mail/?hl=en&shva=1#drafts/128a135f9f439189
[8] Heuristic Algorithms for Siting Alternative-Fuel Stations Using the
Flow-Refueling Location Model, European Journal of Operational Research (2009)
[9]
Intelligent Vehicle and Transport Systems www.hiltechdevelopments.com
[10] GIS Development. 2004. GPS technology to find place in London buses
[Online], Accessed:
http://www.gisdevelopment.net/news/viewn.asp?id=GIS:N_vsmkrtbz [2004 August]
78

FleetMgtSystem PDF

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

FleetMgtSystem PDF

Загружено:

Авторское право:

Доступные форматы

Automatic Fleet Management System

A Thesis submitted in partial fulfillment of the requirements for the degree

Master of Engineering in Software Engineering,

Under the supervision of

Prof. (Dr.) Samiran Chattopadhyay

The thesis at instance is hereby approved as a creditable study of an

(Signature of the examiner)

( Signature of the supervisor )

1.4 Thesis contribution

4.5 Use Case Diagram of the system

Chapter 5 Implementation Details

Delhi Transport Corporation, Delhi

1.2 Thesis Objective

It can be used as a decision support system for implementation of this

1.3 Overall functional activities of this system

Increased overall dispatching and operating efficiency

A simple flow diagram how AFMS works

Box diagram representation of the system (fig-02)

In this dissertation following things have been put together

1.5 Thesis Structure

2.2 Survey of Research Work in this field

Traffic surveillance technologies.

Road Transportation Management using GIS - vehicle

DESIGNING AUTOMATED VEHICLE LOCATION SYSTEMS

Cost Effective GPS-GPRS Based Object Tracking System

Enhanced Mobile Asset Tracking with Telematic Function

2.3 Case Study

Case Study: Delhi Transport Corporation (DTC)

Case Study: Cost Effective GPS-GPRS Based Object Tracking

Summary of Literature survey

So dispatching a nearest vehicle of the route to Breakdown vehicles is the best

AFMS is a Decision Support System. It glues different technologies like

Overall functionality of the Automatic Fleet Management System (Fig-03)

In any vehicle tracking system, the communications infrastructure is the main

Fleet Management Systems

A brief overview of different technologies used in the system is given below:

Provides "Always on" internet access

Chapter 4 System Architecture, Design and Implementation

A brief MVC architecture of this system is given below:

Model View Controller Architecture (MVC) (Fig-06)

Activity diagram shows how to interpret GPS received data (Fig-07)

Activity diagrams show how to create and view device groups(Fig-08)

Activity diagrams show how to create and view an administrator account

Activity diagrams show how to modify and deactivate an account (Fig-12)

Activity diagrams show how to create and view a device by an administrator

Geo-fence is a rectangle, defined by the 2 vertices of its south-west to north-east

Activity diagrams show how to create and view Geofences (Fig-14)

Activity diagram shows how to create a way point(Fig-16)

Activity diagram shows how to generate reports by a user(Fig-17)

E-R Diagram of the system

ER diagram of the AFMS system (Fig-18)

4.4 Database Schema

accountID (primary key)

accountID (primary key) (foreign key)

alarmConditionID (primary key) (system generated numeric ID)

accountID (primary key) (foreign key)

accountID (primary key) (foreign key)

accountID (primary key) (foreign key)

accountID (primary key) (foreign key)

accountID (primary key) (foreign key)

accountID (primary key)

eventSequence (foreign key references EventData table)