RockSoft Consults Limited

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 Department of Information Technology

Jadavpur University,Kolkata

3

ADAVPUR 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 )

4

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

Department of Information Technology

5

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 fleet„s 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 object‟s 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

6

Table of Contents

Acknowledgements

Abstract

Table of contents

List of figures

List of tables

IV

V

VI

VIII

IX

Chapter 1 Introduction 2

1.1 Background 2

1.2 Thesis Objective 3

1.3 Overall functional activities of this system 4

1.4 Thesis contribution 6

1.5 Thesis Structure 6

Chapter 2 Literature Survey 7

2.1 Introduction 7

2.2 Survey of Research work in this field 7

2.2.1 Traffic surveillance technologies 7

2.2.2 Road Transportation Management using GIS - vehicle routing and tracking

7

2.2.3 Designing Automated Vehicle Location Systems for Archived Data Analysis

7

2.2.4 Cost Effective GPS-GPRS Based Object Tracking System

8

2.2.5 Enhanced Mobile Asset Tracking with Telemetry Function

8

2.3 Case study 8

2.3.1 Delhi Transport Corporation (DTC) 8

2.3.2 Cost Effective GPS-GPRS Based Object Tracking System 9

2.4 Summary of Literature survey 10

Chapter 3 Systems Model and Technology

3.1 Overview 11

3.2 Communication System 12

3.3 Fleet Management Systems 12

3.4 Technology Overview 13

Chapter 4 System Design, Architecture

4.1 User Interface 15

4.1.1 N-tier Architecture 15

4.1.2 MVC Architecture 15

4.2 Activity Diagram 16

4.3 E-R Diagram of the system 28

4.4 Database Schema 29

4.5 Use Case Diagram of the system 39

4.6 Algorithm embedded in this model 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 56

6.2 Flow Diagram 57

6.3 Some execution snapshots of this system 58

Chapter 7

Conclusions 67

APPENDIX A 68

APPENDIX B 71

APPENDIX C 73

REFERNCES 78

VII

8

List of Figures

Figure contents Page #

MVC Architecture 16

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

Activity diagrams show how to create and view device groups(Fig-08) 18 Activity diagram for mapping real time and historical device(s) (Fig-09) 19 Activity diagrams show about the login and logout from the AFMS system(Fig-10) 20

Activity diagrams show how to create and view an administrator account in the AFMS system(Fig-11) 21

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

Activity diagrams show how to create and view a device by an administrator (Fig-13) 23

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

Activity diagrams show how an administrator can edit and delete Geofences (Fig-15) 25

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

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

ER diagram of the AFMS system (Fig-18) 28

Use case diagram users access control logic (Fig-19) 40

Use case diagram administrator‟s behavior (Fig-20) 41

Use case diagram communication server (Fig-21) 42

Route layout graph (Fig-21(a)) 43

Implementation diagram of AFMS (Fig-22) 46

Flow diagram of the overall system (Fig-23) 49

Application server functional flow diagram (Fig-24) 50

Movement of a vehicle with different seed (Fig-25) 52

Performance graph of vehicles (Fig-26) 53

System simulation overview (Fig-27) 56

Simulation flow diagram (Fig-28) 57

Login screen of the system Fig-29 59

Main menu screen (Fig-30) 60

Vehicle Map screen (Fig-31) 61

Group Vehicle Map screen (Fig-32) 62

Summary report screen (Fig-33) 63

Account Admin screen (Fig-34) 64

View/Edit User Information screen (Fig-35) 65

Geozone area on map (Fig-36) 66

GPS satellite (picture collected from http://www.ehow.com/facts_5005974_what-waypoint-gps.html ) Fig-37 69

9

List of Tables

Table contents Page #

Geocode Table 51

Comparative study between GPRS Based System and SMS Based System 71

2

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

3

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.

4

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

5

In-Vehicle Equipment

A simple flow diagram how AFMS works

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 .

Satellite

GPS Antenna

GSM Antenna

GSM Modem

GSM

Modem

Application

Server

Database

Server User

Interface

GPS Microwave

Signal

GPS

In-vehicle equipment

Internet

6

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.

7

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 community‟s 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

8

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 object‟s 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.

9

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.

Dispatching of emergency vehicles to Breakdown vehicles or vehicles in 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 object‟s 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

10

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

Dispatching of emergency vehicles to Breakdown vehicles or vehicles in 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.

11

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.

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

GPS

GPRS/GSM

Internet

Vehicle

Mobile Tower

Communication server

Database Server

Applications Running for User

Interface

12

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.

SIM

This SIM is often called VTSIM ( vehicle tracking SIM ) it is configured by the SMS Server

Vehicle Tracking

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 vehicle‟s electrical systems are embedded.

13

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).

14

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.

15

User

Interface

( Web

Browser )

Chapter 4 System Architecture, Design and Implementation

4.1 User Interface

4.1.1 N-tier architecture

Fig-05

In n-tier architecture each tier is related to specific process. User‟s 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 user‟s 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

Web Server ( Apache

Tom Cat )

Application Server ( Sun one Application Server / NetBeans )

Database Server (MySql )

16

( 2) Dispatcher

Business

Logic Action

(3) Update

(5) Extract Model DataSet &

Data Tables

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:

(1) POST

LoginSession.jsp

(4) FORWARD

Client

Browser

(6) Response

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

View ( jsp files)

Controller

(AccountLogin.java

)

17

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

18

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)

19

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.

20

Activity diagram for mapping real time and historical device(s) (Fig-09)

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. .

21

Activity diagrams show about the login and logout from the AFMS system(Fig-10)

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 can‟t do it. The following two activity diagrams show how to create and view administrative account.

22

Activity diagrams show how to create and view an administrator account in the AFMS system(Fig-11)

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.

23

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

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.

24

25

Activity diagrams show how to create and view a device by an administrator (Fig-13)

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.

26

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

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.

27

28

Activity diagrams show how an administrator can edit and delete Geofences (Fig-15)

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)

29

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.

30

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

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)

31

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

30

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.

accountID (primary key) (foreign key) alarmID (primary key) ruleID (primary key) (foreign key) alarmConditionID (foreign key) isMonSelected isTueSelected isWedSelected isThuSelected isFriSelected isSatSelected isSunSelected startTime endTime isActive description lastUpdateTime creationTime

31

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.

accountID (primary key) (foreign key) 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.)

32

6. DeviceGroup: This table defines Account specific Device Groups.

accountID (primary key) (foreign key) 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.

accountID (primary key) (foreign key) groupID (primary key) (foreign key) deviceID (primary key) (foreign key) lastUpdateTime creationTime description lastUpdateUser

8. DeviceRuleMap:

This table defines Device specific Rules.

accountID (primary key) (foreign key) deviceID (primary key) (foreign key) ruleID (primary key) (foreign key) 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

33

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.

accountID (primary key) (foreign key) geofenceID (primary key) latitudeNE longitudeNE latitudeSW longitudeSW displayName description lastUpdateTime creationTime lastUpdateUser

34

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

35

13. GroupList: This table defines the membership of a given User within a DeviceGroup. A Device may be defined in more than one DeviceGroup.

accountID (primary key) (foreign key) 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.

accountID (primary key) (foreign key) deviceID (primary key) (foreign key) userID (primary key) (foreign key) ruleID (primary key) (foreign key) 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

36

16. Resource: This table defines Account specific text resources.

accountID (primary key) (foreign key) resourceID (primary key) title type properties value displayName description lastUpdateTime creationTime lastUpdateUser

17. Role:

This table defines Account specific Roles.

accountID (primary key) (foreign key) roleID (primary key) displayName description notes lastUpdateTime creationTime lastUpdateUser

18. RoleAcl:

This table defines Role specific Access Control permissions.

accountID (primary key) (foreign key) roleID (primary key) (foreign key) aclID (primary key) accessLevel description lastUpdateTime creationTime lastUpdateUser

37

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.

accountID (primary key) (foreign key) 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.

accountID (primary key) (foreign key) userID (primary key) userType password gender contactName contactPhone contactEmail timeZone passwdQueryTime lastLoginTime isActive displayName description notes lastUpdateTime creationTime firstLoginPageID roleID preferredDeviceID lastUpdateUser

38

22. UserAcl: This table defines User specific Access Control permissions.

accountID (primary key) (foreign key) userID (primary key) (foreign key) 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)

39

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.

40

41

Fig-20 The above use case diagram shows administrator‟s 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.

42

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