GIS/GPS/GPRS and Web based Framework for Vehicle Fleet Tracking

The paper presents the combined application of Geographical Information Systems (GIS), the Global Positioning System (GPS), the General Packet Radio Service (GPRS) and the Internet for tracking of vehicle fleets. It is one component of an enterprise solution that is designed to manage and track a large fleet. The key features of the system are an open-source GIS platform, real-time location information update, and a web-based user interface. The system consists of GPS-based vehicle tracking devices, a communications server, a web-server, a database server, and a map server. The tracking devices mounted in the vehicles collect location information in real-time via the GPS. This information is transferred continuously through GPRS to a central database. The users are able to view the current location of each of the vehicles in the fleet via a web-based application, and thereby manage the fleet. The vehicle positions and other related information are displayed on a digital map, which is made available by a map server. It is a typical example of how the advantages of ICTs may be leveraged for the efficient and effective management of a company's resources, particularly in the face of skyrocketing fuel costs.


Introduction
The fleet tracking system presented in this paper is a system that is designed to track and manage vehicles that are owned or used by an enterprise, using a combination of several modern information and communications technologies.
The system comprises of vehicle-mounted tracking devices, a central server system and a web-based application. Through this system, users will have the facility of monitoring the location graphically (on a digital map) and other relevant information of each vehicle in the fleet.
The paper highlights the design and developments related to the fleet tracking aspect of the system. However, the system also comprises of a number of modules to manage resources of the system (drivers, vehicles), efficient utilization (tour allocation to vehicles) as well as report generation and auditing of activities.
The system is designed to serve enterprises with large vehicle fleets and complex usage requirements. Employees may need to use vehicles frequently for short trips, and some for long-distance travel. Some trips may need to be scheduled at short notice, while some may need to be on a daily schedule. Employees may need to be picked up, or dropped at particular points in a journey, and vehicles needing repairs need to be temporarily made unavailable. These and many more functions need to be facilitated by an effective fleet management system. As such, the requirements that need to be satisfied are diverse. Central management of such large fleets is essential in the context of the overall productivity improvement of an organization.
The paper illustrates the integration of multiple technologies to achieve a common goal. It is a case study of an example that shows how such technologies can be synergistically combined to address a real world problem.

Objectives
The main objective of the proposed system is to provide a solution to the following problems that exist in a large enterprise: • Lack of a proper system to keep track of a large fleet of vehicles in real-time • Loss of productivity due to lack of timely means of transport for employees for company work • Loss of productivity due to inefficient utilization and unauthorized use of vehicles.
The system presented attempts to solve the above problems with a robust solution with: • an easy to use web interface, • a widespread, already available, communications infrastructure, • an easy-to-understand geo-information display and • Open source tools to reduce the system cost

Technology Overview
Currently, there are several tracking solutions of different forms. Some operate in client-server architecture, while some others work in standalone mode. Most of the client-server solutions are designed to provide tracking only. While a client-server system is a better solution when considering cost, a standalone solution will give better performance in terms of speed of response. There are other trade-offs such as upgrading of geo-information, which is convenient in a client-server environment. The upgrade can be done at the server end. In a standalone solution, geo-information needs to be upgraded in each instance of the application.
Some tracking service providers keep the location information in their own database. Users access this information, sometimes over international telecommunication infrastructure, and pay per access. SMS (Short Message Service) available in mobile networks is another mode of information transfer available in such systems. In these systems, the user organization has limited flexibility and has to bear a relatively higher cost.

System Architecture
The fleet tracking system addresses the above constraints and trade-offs to provide a webbased solution. The architecture is client-server architecture where the web browser is the client, and the server functions are shared between a web server, a communications server, a database server and a map server. An open source platform is selected for the map server in order to make the solution cost effective [5,6].
GPRS (General Packet Radio Service) is chosen as the main method of communication between the tracking unit and the server. GPRS, being a 2.5G mobile technology, is ubiquitously available in the country. It is also ideally suitable for data transfer over an always on-line connection between a central location and mobile devices. The cost is per kilobyte of data transferred, in comparison to SMS where the cost is per message.
The location information collected through the GPS in real time is deposited in a central database that is owned by the user organization. Each user of the system may access this information via the Internet. Figure 1 shows the chosen system architecture.

System Design
This section describes the hardware and software design of the system as well as the functionalities of each component.

Hardware Design
The tracking unit collects the location information via the GPS, formats this information into a system-specific packet format and sends it to the server via GPRS. If GPRS is unavailable at any time, time-stamped data packets are stored in a temporary storage unit to be uploaded when GPRS becomes available again. Thus, the movement information of a vehicle is not lost even in the event of a communications failure.
The device comprises of a microcontroller 1 , a GSM module 2 , a GPS receiver, a data storage unit and a power source. A block diagram of the tracking unit is shown in Figure 2.
The microcontroller is the main operational unit of the tracking device. It communicates with each of the other operational units via its I/O interfaces.
The GPS receiver within the tracking unit will collect the latitude, longitude and speed information and send to the microcontroller. Then the GSM module communicates with the microcontroller to access and send this data to the server via a previously established GPRS connection. First, the unit will establish a GPRS connection with the server, and then establish a TCP/IP socket connection with the data sent as IP data packets over this connection.
The tracking unit is designed to be powered by the vehicle battery. However, a power source is built into the device as an emergency backup.
In the event that there is no GPRS available, the GPS data is stored in the memory unit and will be sent to the server along with the real time location details as soon as GPRS becomes available again.

Software Design
The main software components of the system are the socket communication server, the web server work and the GIS map server.
The socket communication server is the central server component that communicates with the tracking units. It establishes TCP/IP socket connections with the remote hardware units. It is capable of communicating with multiple client units using multiple threads. A customdefined application level protocol is used for transfer of data. The sever will create a TCP socket and will bind the application to the relevant port. It will then listen to any incoming connections.
When a client (a remote tracking device) connects, the server will authenticate and acknowledge the client. Then, the server will proceed to receive the information from the client device and will store them in the database server.
The web application will retrieve the data from the database server and do preprocessing for further operations as requested by the user. The web application is also the main management tool of the system. Users log into the system via this application, and gain access to different functional modules depending on his/her authentication level.

Geo-Inf ormation Components
The Geo-data module deals with all spatial information in the system. The main geo information components are Locations, Geofences, Routes and Tours.
Locations are cities, towns, other identifiable landmarks as well as vehicle parks of the user organization.
Geo-fences are circular areas defined around a Location. The user is able to define the radius of this area. The GPS location of the center of the circle and the radius define a Geo-fence. In the tracking system, a vehicle is determined to be at a particular Location if it is within this Geofence.
A Route comprises of two or more Locations described above. A Route can be created by adding a series of Locations in order. Major highways as well as minor routes can be added to the system as Routes in this manner.
These Routes allow an operator of the system to define a Tour for a particular vehicle from the required origination to the destination point. When a vehicle needs to be reserved for a particular trip, the system operator creates the Tour by combining parts of the pre-defined Routes. For example when the vehicle needs to travel from Colombo to Horana, and pick up a person at Mt. Lavinia on the way, a Tour may be defined by joining the Colombo-Katubedda segment from the Colombo-Galle Route, the Katubedda-Piliyandala Route and the Piliyandala-Horana segment from the Colombo-Horana Route. Once the vehicle is along the way, it can be tracked and alerts sent via SMS to authorized persons if any deviations are observed in the Tour or the schedule assigned to the vehicle. In this manner, geo-information can be used to meet the requirement of the enterprise.

B t b p
BorelU Police y

Figure 4 -Route Admin
The Geo-data module allows authorized users to create Locations, Geo-fences, Routes and Tours. Location, Route and Tour creation are supported by maps for easy operation and visual verification. This is done through a graphical user interface including digital maps. For example, a mouse click on a particular city can be used to retrieve its coordinates, which can be then defined as a Location. The interface for Route creation is shown in Figure 4.
While the vehicle is on tour, the system tracks its position in real-time and is able to detect if it deviates from the defined tour.

Open Source CIS Tools
For the development of the mapping component of the fleet management system, an open source development environment is used namely, MapServer [4]. This is the GIS tool which is used to display geographical information on a map which is in a widely accepted standard format for digital maps.
MapServer is excellent at rendering spatial data such as maps, images, and vector data for the web. Beyond browsing GIS data, MapServer also allows the creation of geographic image maps which can direct users to content on the web.
Digital maps that were used are in the .shp format, while the accompanying information is contained in database files in the .dbf format.
The maps are displayed with information in the database files presented as different layers.
These layers of geo-information are loaded dynamically by the client application of the system as per the user requests.
In the tracking module, the GIS data is passed to the map server which generates the map including that data. Then it generates a .jpeg image and passes it to the web server, which displays the image on a browser. All Map processing is done on the map server.
Along with the location information, the tracking device also sends other relevant data such as speed, time, and power level to the socket communication server. This information is also stored in the database. In the tracking module these data will be displayed along with the vehicle number which is being tracked. The Map events such as zoom in, zoom out and panning are implemented in this module as processing functions in the map server. The outputs of these functions are sent to the web server and then to the browser for display as images. Figure 5 shows a vehicle information display in the fleet tracking module.

Results, Conclusions and Future Enhancements
This paper presents the development of a fleet tracking system using GIS technologies, the GPS and GPRS. It is a typical example of how the advantages of ICTs may be leveraged for the efficient and effective management of a company's resources, particularly in the face of sky-rocketing fuel costs.
In selecting the technologies and the architecture to support this system, several existing platforms for similar purposes were evaluated. Based on the ease of implementation and operating cost, the presented technologies and architecture were selected.
On the trial runs conducted, the system displays the location of moving vehicles with an error less than 50m in real time on the Map. It clearly indicates and distinguish each vehicle on the map as they move on road. When GPRS connectivity is lost, the location is not updated on the map. However, when connectivity is reestablished, the data stored on-board the tracking device is uploaded to the database. Accuracy of the system is higly dependant on the GPS data received while the reliability and the usability depend on the realiability of the mobile communications network.This kind of an application is very useful in areas where there is wide mobile network coverage.
In the fleet management system, the client application is a PC-based web browser. Though this application can be accessed by a mobile client, it is not optimized for this mode of operation. A possible future enhancement is to make some of the modules available in an efficient manner to mobile clients as well. In this, particular attention should be directed to storage and rendering maps in a suitable manner on mobile devices.