FATIH UNIVERSITY
FACULTY OF ENGINEERING
VEHICLE TRACKING SYSTEM VIA MOBILE PHONES
by
Ertuğrul YILMAZ & Şeyh Halil BAYRAM
Advisor: Ins. Aişe Zulal ŞEVKLİ
June 2006
i
VEHICLE TRACKING SYSTEM VIA MOBILE PHONES
by
Ertuğrul YILMAZ & Şeyh Halil BAYRAM
A Senior Design Final Report Submitted to
The Department of Computer Engineering
of
Fatih University
in partial fulfillment of the requirements for the degree of
Bachelor of Science
in
Computer Engineering
June 2006
Istanbul, Turkey
ii
ABSTRACT
VEHICLE TRACKING SYSTEM VIA MOBILE PHONES
Ertuğrul YILMAZ & Şeyh Halil BAYRAM
Computer Engineering
June 2006
Advisor: Ins. Aişe Zulal ŞEVKLİ
The purpose of the project MobitrackX is to develop an application for mobile
phones to provide tracking detailed locations of vehicles, and some vehicle related
information by using GPS and GPRS technologies. This project is based on Mobitrack.
Mobitrack is a commercial application and is being used currently. MobitrackX
provides vehicle tracking services on the mobile phone. MobitrackX system consists of
GPS and GPRS enabled microcontrollers located in vehicles, Servlets and DBMS
running on the server, geographic information retrieved from the GIS server, and Java
application running on the mobile phone. MobitrackX has been created as an extension
to the Mobitrack infrastructure.
iii
TABLE OF CONTENTS
ABSTRACT..................................................................................................................... iii
TABLE OF CONTENTS................................................................................................. iv
LIST OF FIGURES ......................................................................................................... vi
LIST OF TABLES .......................................................................................................... vii
LIST OF SYMBOLS AND ABBREVIATONS ........................................................... viii
CHAPTER 1 INTRODUCTION ..................................................................................... 1
1.1 PROBLEM DEFINITION ...................................................................................... 1
1.2 RELATED WORK ................................................................................................. 2
1.2.1 Vehicle Tracking Systems in Turkey............................................................... 2
1.2.2 Mobitrack – Fleet Management System .......................................................... 2
CHAPTER 2 BACKGROUND ....................................................................................... 6
2.1 GPS ......................................................................................................................... 6
2.1.1 GPS Segments.................................................................................................. 6
2.1.1.1 Satellites .................................................................................................... 6
2.1.1.2 Control Segments ...................................................................................... 7
2.1.1.3 User Segment ............................................................................................ 8
2.1.2 GPS Navigation, Positioning and Trilateration ............................................... 8
2.2 GPRS ...................................................................................................................... 9
2.2.1. GPRS Basics ................................................................................................. 10
2.2.2. GPRS Multislot Classes ................................................................................ 10
2.2.3. GPRS Capability Classes .............................................................................. 12
2.3 GIS ........................................................................................................................ 13
2.3.1. Server-Based GIS Technology ..................................................................... 14
2.3.2. Views of a GIS .............................................................................................. 14
2.3.2.1. The Database View ................................................................................ 14
2.3.2.2. The Map View ....................................................................................... 14
2.3.2.3. The Model View .................................................................................... 15
CHAPTER 3 SYSTEM DESIGN ................................................................................... 15
3.1 Functional Requirements ...................................................................................... 15
3.1.1 Downloading MobitrackX from the web ....................................................... 15
3.1.2 Installing the MobitrackX .............................................................................. 16
3.1.3 Starting the MobitrackX application.............................................................. 16
3.1.4 Stopping the MobitrackX application ............................................................ 16
3.1.5 Viewing the list of vehicles ........................................................................... 16
3.1.6 Viewing the vehicle related information ....................................................... 16
3.1.7 Sending SMS to the vehicle ........................................................................... 16
3.1.8 Setting the Data Sending Frequency .............................................................. 17
3.1.9 How to Control Vehicle ................................................................................. 17
3.1.9.1 Stop the Engine ....................................................................................... 17
3.1.9.2 Turn the Flashes On/Off ......................................................................... 17
3.1.9.3 Lock / Unlock the Doors ......................................................................... 17
3.1.10 Viewing a Vehicle on the Map .................................................................... 17
3.2 Nonfunctional Requirements ................................................................................ 18
3.2.1 Usability ......................................................................................................... 18
3.2.2 Reliability....................................................................................................... 18
iv
3.2.3 Performance ................................................................................................... 19
3.2.4 Implementation Platform ............................................................................... 19
3.3 System Structure ................................................................................................... 19
3.3.1 Mobitrack Vehicle ......................................................................................... 20
3.3.2 Mobitrack Server ........................................................................................... 21
3.3.3 GIS Server...................................................................................................... 22
CHAPTER 4 IMPLEMENTATION .............................................................................. 23
4.1 PCMEF Package Framework................................................................................ 24
4.1.1 Layers............................................................................................................. 24
4.1.2 PCMEF Principles ......................................................................................... 25
4.2 MobitrackX Package Structure ............................................................................. 25
4.2.1 MobitrackX Presentation Package ................................................................. 26
4.2.1.1 MobitrackX.java ..................................................................................... 27
4.2.1.2 Other Classes In Presentation Package ................................................... 28
4.2.2 MobitrackX Control Package ........................................................................ 29
4.2.2.1 CActioner (Figure 4.4) ............................................................................ 29
4.2.2.2 CMapCanvas (Figure 4.4)....................................................................... 31
4.2.3 MobitrackX Mediator Package ...................................................................... 32
4.2.3.1 kXML Package ....................................................................................... 33
4.2.3.2 MMapBroker (Figure 4.6) ...................................................................... 33
4.2.3.3 MUserBroker (Figure 4.6) ...................................................................... 34
4.2.3.4 MVehicleBroker (Figure 4.6) ................................................................. 35
4.2.4 MobitrackX Foundation Package .................................................................. 36
4.2.4.1 Login.java ............................................................................................... 36
4.2.4.2 Logout.java ............................................................................................. 36
4.2.4.3 GetUnitInfo.java ..................................................................................... 36
4.3 User Interface ........................................................................................................ 38
4.3.1 Login Form .................................................................................................... 38
4.3.2 Vehicle List .................................................................................................... 38
4.3.3 Vehicle Details ............................................................................................... 38
4.3.4 Commands ..................................................................................................... 39
4.3.5 Vehicle Control .............................................................................................. 39
4.3.6 Send SMS ...................................................................................................... 39
4.3.7 Change Data Frequency ................................................................................. 40
4.3.8 Map Screen .................................................................................................... 41
CHAPTER 5 CONCLUSION ........................................................................................ 43
REFERENCES ............................................................................................................... 44
v
LIST OF FIGURES
Figure 1.1 Mobitrack Fleet Summary Frame.................................................................... 2
Figure 1.2 Mobitrack Map Frame ..................................................................................... 3
Figure 1.3 Mobitrack Options Frame ............................................................................... 3
Figure 1.4 Mobitrack Address Search Tab ....................................................................... 4
Figure 1.5 Mobitrack Vehicle Commands Tab ................................................................ 4
Figure 2.1 Constellation of 24 Satellites ........................................................................... 7
Figure 2.2 GPS NAVIGATION ....................................................................................... 8
Figure 2.3 Trilateration in 2D ........................................................................................... 9
Figure 2.4 A map from GIS ............................................................................................ 13
Figure 3. 1 Structure of the whole system ...................................................................... 20
Figure 3. 2 Inside the Mobitrack Server ......................................................................... 21
Figure 3. 3 Cylindrical Projection Method ..................................................................... 22
Figure 3. 4 2D World Map.............................................................................................. 23
Figure 4. 1 PCMEF Package Framework. ...................................................................... 24
Figure 4. 2 MobitrackX packages ................................................................................... 26
Figure 4. 3 MobitrackX Presentation Package ............................................................... 27
Figure 4. 4 MobitrackX Control package ....................................................................... 29
Figure 4. 5 J2ME Midlet and RMS interfacing .............................................................. 30
Figure 4. 6 MobitrackX mediator package. .................................................................... 33
Figure 4. 7 Returned XML After a Successful Login..................................................... 34
Figure 4. 8 Returned XML Consisting of Two Vehicles ................................................ 35
Figure 4. 9 Sequence Diagram for Login and VehicleList ............................................. 37
Figure 4.10 Screenshot of Vehicle List and Vehicle Details ......................................... 38
Figure 4. 11 Screenshot of Commands and Vehicle Control ......................................... 39
Figure 4. 12 Screenshot of Send SMS and Change Data Frequency .............................. 40
Figure 4. 13 Country and Region View Of The Map Screen ......................................... 40
vi
LIST OF TABLES
Table 2. 1 Internet connection speeds for some technologies ........................................ 10
Table 2.2 Multislot class slots......................................................................................... 11
Table 2.3 Multislot class details ..................................................................................... 12
Table 4. 1 RecordStore Structure .................................................................................... 30
vii
LIST OF SYMBOLS AND ABBREVIATONS
GPS
GPRS
DBMS
GIS
SMS
3D
GSM
CSD
Kbps
CLDC
J2ME
IDE
PCMEF
GUI
XML
LCDUI
RMS
URL
Global Positioning System
General Packet Radio Service
Database Management System
Geographic Information System
Short Message Service
Three Dimensional
Global System for Mobile Communications
Circuit Switched Data
Kilobits per second
Connected Limited Devices Configuration
Java Platform, Micro Edition
Integrated Development Environment
Presentation - Control - Mediator - Entity - Foundation
Graphical Use Interface
Extensible Markup Language
Limited Connected User Interface
Record Management System
Uniform Resource Locator
viii
CHAPTER 1
INTRODUCTION
1.1 PROBLEM DEFINITION
It was not until Alexander Graham Bell said "Mr. Watson, come here, I want
you!" over a wire filled with a special Liquid Transmitter, that we have a channel other
than the air to communicate each other in terms of speech.
Recently we went back to the past again by using the air as a communication
channel, in a different sense, to talk to each other. Mobile phones then quickly spread
out the world and became a must have stuff. The reason that the mobile phone accepted
by the community quickly is providing mobility and freedom to the people.
In our project we motivated on developing a system to provide mobility to the
current users of Mobitrack. As a mobile extension of Mobitrack, MobitrackX provides
basic vehicle tracking services by using Mobitrack system infrastructure. MobitrackX is
a Java supported mobile phone application. Target users of this system vary from
hospitals, freight companies, transporting companies to banks.
MobitrackX is consisting of three tiers which are; GPS and GPRS enabled
microcontroller residing in the vehicles, servers, and Java enabled mobile phone. Web
services, Java servlets, and DBMS are running on the local server. The maps are
retrieved from a GIS server. And MobitrackX is running on mobile phones.
Viewing the vehicles on the map is not the only functionality that is supported by
MobitrackX. Detailed address, driver information, speed of all the vehicles can also be
viewed. Playing with the interior functions within a particular vehicle which includes
running and stopping the engine, switching on and switching off the flashers, and
sending SMS to the driver of the vehicle, is also provided with the system.
Although designed system is a vehicle tracking application, it can be used as map
guide because variety of operations on map is allowed. After locating herself on the
map, user can find her directions to the intended place by using the street detailed map.
As an application running on mobile phones, MobitrackX is unique in the area of
vehicle tracking in Turkey.
1
1.2 RELATED WORK
1.2.1 Vehicle Tracking Systems in Turkey
The United States Department of Defense, which installed and has been
maintaining the GPS system, made it available for civilian use in 1980s. The DoD has
been providing new technologies to improve the accuracy of position that civilian
applications retrieve. Since then GPS has been in use in many location based
applications, including vehicle tracking, worldwide.
After surveying the existing companies working on vehicle tracking, one will
realize that there are only a few of them in Turkey. Solit&Zebra, the creator of
Mobitrack is one these companies. Fortunately we had opportunity of working in
corporation with this company while implementing the project.
1.2.2 Mobitrack – Fleet Management System
Mobitrack is a commercial product designed especially to track fleet of
companies working in the areas of freight and transportation. Besides tracking the
vehicles in the fleet users are able to intervene to a particular vehicle. Some of available
interventions are: stopping the engine, turning on the flashes and locking the doors.
Figure 1 - Figure 5 are the frames of the screen to be shown to the user of Mobitrack.
Figure 1.1 Mobitrack Fleet Summary Frame
In the fleet summary frame the groups within the fleet are displayed in the left
side, the details of the vehicles which are in the selected group are displayed in the right
side. The most important displayed information about a vehicle includes its model
name, plate identity, address, speed, and last data transmission time. Last data
transmission time is the time the vehicle lastly sent information to the system regarding
its position and interior.
2
Figure 1.2 Mobitrack Map Frame
In the map frame, all the vehicles belonging to the selected group are shown on
the map with default zooming scale. Zoom scale of the displayed map can be change d
in two ways. First way is selecting the zoom-in, zoom-out icons on the top left and
clicking on the point which is going to be center of the new scaled map. Second way is
selecting the zoom scale from the drop down list on top left. A new map with the
selected scale and the same center will be retrieved and displayed.
Figure 1.3 Mobitrack Options Frame
All the information of a selected vehicle is displayed on options frame by
default. In addition to the vehicle summary displayed on Fleet Summary Frame, name
3
and cell phone number of the vehicle’s driver, latitude and longitude of the vehicle, and
IMEI number of the device installed to that vehicle is displayed. Some applicable
information can be changed and saved too.
The rest of the tabs on this frame are about reports, address search, and
commands. Reports can be documented for a given time interval. For an entered time
interval some of the important information regarding that vehicle can be displayed,
printed and also saved to the computer. This option is provided for archiving and also
searching in history purposes.
Figure 1.4 Mobitrack Address Search Tab
By selecting the city, county, region and street information and clicking the
show button respectively, user can see the map of the place with an appropriate
zooming scale on the map frame.
Figure 1.5 Mobitrack Vehicle Commands Tab
4
The provided operations on Vehicle Commands Tab are, sending SMS to the
driver, changing the data transmission frequency of the device, querying the device, and
intervening operations. Querying the device means triggering the device to transmit
vehicle related data to the system immediately regardless the data transmission
frequency which is set before. The intervening operations are turning the flashers
on/off, running/stopping the engine, and resetting the distance counter of the vehicle.
5
CHAPTER 2
BACKGROUND
2.1 GPS
GPS which refers to The Navstar Global Positioning System, consists of three
segments or components:
 A constellation of satellites transmitting microwave signals on two frequencies
and orbiting about 20,200 km above the earth’s surface.
 A control segment which maintains GPS through a system of ground monitor
stations and satellite upload facilities.
 The user receivers.
The signals which is transmitted by the satellite as a unique digital code sequence
of 1’s and 0’s is picked up by a GPS receiver’s antenna and matched with the same code
sequence generated inside the receiver. By matching the signals, the receiver determines
how long it takes the signals to travel from the satellite to the receiver. Based on the
speed of radio waves, which is the same speed with the light (300,000 kilometers per
second), these timing measurements are converted to distances.
GPS receiver sychronizes its clock with the GPS time standart by receiving
signals from four or more satellites simultaneously. Having a precise clock and
measuring the distances to four or more satellites in known locations, the receiver can
locate itself by means of latitude, longitude and altitude. Locations of the satellites are
included with the signals transmitted by the satellites.
Determining a position from measurements of distances is known as trilateration.
2.1.1 GPS Segments
2.1.1.1 Satellites
The GPS system uses a satellite constellation of at least 24 active satellites in
intermediate circular orbits (Figure 1.1). The constellation includes three spare satellites
6
in orbit, in case of any failure. Each satellite circles the Earth exactly twice each day at
an altitude of 20,200 kilometers. The orbits are aligned so at least four satellites are
always within line of sight from almost any place on Earth. To be line of sight from a
point means having a visual contact with that point. For instance a satellite which is
currently in a position perpendicular to the North Pole is not line of sight with a GPS
receiver located on the South Pole.
Figure 2.1 Constellation of 24 Satellites [10]
Each satellite repeatedly re-broadcasts the exact time according to its internal
atomic clock along with a digital data packet. The data includes the orbital elements of
the satellite's precise position, satellite status messages, and an almanac of the
approximate position of every other active GPS satellite. The almanac lets GPS
receivers use data from the strongest satellite signal to locate other satellites.
2.1.1.2 Control Segments
The flight paths of the satellites are measured by five monitor stations around the
world (Hawaii, Kwajalein, Ascension Island, Diego Garcia, Colorado Springs). The
master control station, at Schriever AFB, processes their combined observations and
sends updates to the satellites through the stations at Ascension Island, Diego Garcia,
and Kwajalein. The updates synchronize the atomic clocks on board each satellite to
within one microsecond and also adjust the ephemeris of the satellites' internal orbital
model to match the observations of the satellites from the ground.
7
2.1.1.3 User Segment
GPS receivers calculate their current position (latitude, longitude, altitude), and
the precise time, using the process of Trilateration. This involves measuring the distance
to at least four satellites by comparing the satellites' coded time signal (PRN Code)
transmissions. The receiver calculates the orbit of each satellite based on information
encoded in their radio signals, and measures the distance to each satellite, called a
pseudo range, based on the time delay from when the satellite signals were sent until
they were received.
2.1.2 GPS Navigation, Positioning and Trilateration
GPS receivers convert SV signals into position, velocity, and time estimates. Four
satellites are required to compute the four dimensions of X, Y, Z (position) and Time.
GPS receivers are used for navigation, positioning, time dissemination, and other
research.
Figure 2.2 GPS NAVIGATION [10]
Refer to the Figure 2.3 for the following explanation. In order to locate itself on
the Earth a GPS Receiver is using 3D Trilateration. The steps to locate a point on a
plane are discussed here. Considering the point B, we want to know location of point B
relative to the reference points P1, P2, and P3. Measuring r1 narrows the position down
to a circle. Next, measuring r2 narrows it down to two points, A and B. A third
8
measurement, r3, gives the coordinates at B. A fourth measurement could also be made
to reduce error.
Figure 2.3 Trilateration in 2D
2.2 GPRS
GPRS (General Packet Radio Service) is the world's most ubiquitous wireless data
service, available now with almost every GSM network. GPRS is a connectivity
solution based on Internet Protocols that supports a wide range of enterprise and
consumer applications. With throughput rates of up to 40Kbit/s, users have a similar
access speed to a dial-up modem, but with the convenience of being able to connect
from anywhere. GPRS customers enjoy advanced, feature-rich data services such as
color Internet browsing, e-mail on when moving, and powerful visual communications
such as video streaming, multimedia messages and location-based services. In Table 2.1
upload and download for GPS and other technologies are shown.
9
Type
Upload
Download
GPRS
14 kbps
28-64 kbps
GSM CSD
9.6-14 kbps
9.6-14 kbps
HSCSD
28 kbps
28 kbps
Dial-UP
56 kbps
56 kbps
ISDN
64 kbps
64 kbps
256-1024
512-2048
Standard
ADSL
kbps
Broadband
kbps
2 Mbps
2 Mbps
Table 2. 1 Internet connection speeds for some technologies [4]
2.2.1. GPRS Basics
GPRS is different from the older Circuit Switched Data connection included in
GSM standards releases before Release 97. In CSD (Circuit Switched Data), a data
connection establishes a circuit, and reserves the full bandwidth of that circuit during
the lifetime of the connection. GPRS is packet-switched which means that multiple
users share the same transmission channel, only transmitting when they have data to
send. This means that the total available bandwidth can be immediately dedicated to
those users who are actually sending at any given moment, providing higher utilization
where users only send or receive data in some intervals. Web browsing, receiving emails as they arrive and instant messaging are examples of uses that require intermittent
data transfers, which benefit from sharing the available bandwidth. Usually, GPRS data
is billed per kilobytes of information transceived while circuit-switched data
connections are billed per seconds.
2.2.2. GPRS Multislot Classes
The class of the device that has GPRS determines the speed at which GPRS can
be used. For example, the majority of GPRS terminals will be able to download data at
speeds of up to 24Kbps (kilobytes per second). At the higher end, speeds are
theoretically possible up to171.2Kbit/sec when 8 slots are assigned at the same time to a
10
single user. In reality it is 40-50Kbps. PC cards capable of GPRS will send data up to
speeds of 48Kbps.
Multislot classes (Table 2.2) are product dependant, and determine the maximum
achievable data rates in both the uplink and downlink directions.
Written as (for example) 3+1 or 2+2, the first number indicates the amount of
downlink timeslots (what the mobile phone is able to receive from the network).
The second number indicates the amount of uplink timeslots (how many timeslots the
mobile phone is able to transmit).
The active slots determine the total number of slots the GPRS device can use
simultaneously for both uplink and downlink communications.
Multislot
Class
Downlin
Uplin
Activ
k Slots
k Slots
e Slots
1
1
1
2
2
2
1
3
3
2
2
3
4
3
1
4
5
2
2
4
6
3
2
4
7
3
3
4
8
4
1
5
9
3
2
5
10
4
2
5
11
4
3
5
12
4
4
5
Table 2.2 Multislot class slots [4]
11
Details for each multislot class of GPRS is given in Table 2.3.
Class 2
Class 4
One Up, Two Down - (2+1)
One Up, Three Down - (3+1)
8-12Kbps Send - 16-24Kbps
8-12Kbps Send - 24-36Kbps
Receive
Receive
Motorola Accompli A008
Motorola TimeportT260
Trium Mondo, Sirius
Class 6 - Configurable between
Class 8
Two Up, Three Down
One Up, Four Down
16-24Kbps Send - 24-36Kbps
8-12Kbps Send - 32-40Kbps
Receive
Receive
Or Three Up, Two Down
Ericsson T39, R520
24-36Kbps Send - 16-24Kbps
Motorola v60i, v66i
Receive
Samsung Q200, S100
Nokia 6310, 6510, 8310
Siemens S45, ME45, M50
Trium
Eclipse
Class 10- Configurable between
Class 12- Configurable between
One Up, Four Down
One Up, Four Down
8-12Kbps Send - 32-48Kbps
8-12Kbps Send - 32-48Kbps
Receive
Receive
Or Two Up, Three Down
Or Two Up, Three Down
16-24Kbps Send - 24-36Kbps
16-24Kbps Send - 24-36Kbps
Receive
Receive
Philips Fisio 820
Or Three Up, Two Down
24-36Kbps Send - 16-24Kbps
Receive
Or Four Up, One Down
32-48Kbps Send - 8-12Kbps
Receive
Sierra Wireless Aircard 750
GSM/GPRS PC Card
Table 2.3 Multislot class details [4]
2.2.3. GPRS Capability Classes
Class indicates capability of a mobile phone with respect to connecting through
GPRS and GSM services.
 Class A
Class A mobile phones can be connected to both GPRS and GSM services
simultaneously.
 Class B
12
Class B mobile phones can be attached to both GPRS and GSM services, using
one service at a time. Class B enables making or receiving a voice call, or
sending/receiving an SMS during a GPRS connection. During voice calls or SMS,
GPRS services are suspended and then resumed automatically after the call or SMS
session has ended.
 Class C
Class C mobile phones are attached to either GPRS or GSM voice service. You
need to switch manually between services.
2.3 GIS
GIS (geographic information system) is a collection of computer hardware,
software, and geographic data for capturing, managing, analyzing, and displaying all
forms of geographically referenced information.
With a GIS, you can link information (attributes) to location data, such as people
to addresses, buildings to parcels, or streets within a network. You can then layer that
information to give you a better understanding of how it all works together. You choose
what layers to combine based on what questions you need to answer.
Figure 2.4 A map from GIS
13
2.3.1. Server-Based GIS Technology
Server based GIS is used for many kinds of centrally hosted GIS computing. The
server-based GIS technology trend is growing. GIS software can be centralized in
application servers to deliver GIS capabilities to large numbers of users over networks
as we will see in our project. Enterprise GIS users connect to central GIS servers using
web browsers, mobile computing devices, and other digital tools.
Comprehensive GIS capabilities must be provided to support a broad range of
server GIS requirements. For example, server GIS can be used for:
 Managing large GIS databases
 Internet delivery of geographic information
 Hosting central GIS Web portals for information discovery and use
 Centrally hosting GIS functions that are accessed by many users in an
organization
 Distributed GIS computing (such as distributed GIS data management and
analysis)
 Internet delivery of comprehensive GIS functionality
2.3.2. Views of a GIS
A GIS is most often associated with maps. A map, however, is only one way you
can work with geographic data in a GIS, and only one type of product generated by a
GIS. There are basically three views of a GIS: Database View, Map View, and Model
View.
2.3.2.1. The Database View
A GIS is a unique kind of database of the world—a geographic database
(geodatabase). It is an "Information System for Geography." Fundamentally, a GIS is
based on a structured database that describes the world in geographic terms.
2.3.2.2. The Map View
A GIS is a set of intelligent maps and other views that show features and feature
relationships on the earth's surface. Maps of the underlying geographic information can
14
be constructed and used as "windows into the database" to support queries, analysis, and
editing of the information. This is called geovisualization.
2.3.2.3. The Model View
A GIS is a set of information transformation tools that derive new geographic
datasets from existing datasets. These geoprocessing functions take information from
existing datasets, apply analytic functions, and write results into new derived datasets.
CHAPTER 3
SYSTEM DESIGN
3.1 Functional Requirements
The application MobitrackX will be used by the current users of existing
Mobitrack web application. User’s tasks include downloading, installing and using the
application. The user tasks and the behavior of the system lead to the following
functional requirements:
3.1.1 Downloading MobitrackX from the web
User will download the application from web through the mobile phone’s GPRS
connection. There are several compiled .jar files for mobile phones have different
features: one .jar for phones supporting CLDC 1.0 and one for CLDC 1.1. Also there
are two language options for MobitrackX: Turkish and English. After downloading one
of these .jar files it will be saved on to the phones local directory system. The
application .jar files can be downloaded from these web addresses.
http://www.mobitrack.net/MOBITRACKX_CLDC1_0_TR
http://www.mobitrack.net/MOBITRACKX_CLDC1_1_EN
http://www.mobitrack.net/MOBITRACKX_CLDC1_0_EN
http://www.mobitrack.net/MOBITRACKX_CLDC1_1_TR
15
3.1.2 Installing the MobitrackX
After downloading the MobitrackX.jar application is automatically installed on
the mobile phone.
3.1.3 Starting the MobitrackX application
User will select the application and start it. After starting the application users will
be asked for username and password. If the user is authenticated then the default view
of the system will be shown. Default view contains the list of the vehicles that the user
is authenticated to see. The system is now ready for user to use.
3.1.4 Stopping the MobitrackX application
The exit option will reside in menu option which will show in all the screens. By
choosing this option user will exit the application.
3.1.5 Viewing the list of vehicles
After authentication the list of vehicles will automatically be shown. If the user is
on any other menu, he/she will be able to choose to go back to this view by using an
option in the common screen menu.
3.1.6 Viewing the vehicle related information
On the default view of the application, user can see all the vehicles and can select
the vehicle about which more detailed information is required to be seen. After first
login to MobitrackX application if user has a number of vehicles, summaries of those
vehicles are stored into mobile phone’s memory. Unless user refresh the vehicle list that
list is shown whenever user logins. After selection of vehicle, user will select detailed
info option on the menu in order to see detailed information about a vehicle.
Detailed
information about a vehicle includes: name of the vehicle, license plate number, name
of the driver, velocity of the vehicle, and the address of the vehicle.
3.1.7 Sending SMS to the vehicle
“Sending an SMS” option is in the “Commands Screen” which can be viewed
from the common menu. After selection of this option, a screen with a textbox will be
shown and filled by the user; “clearing the textbox” and “sending the written message”
options reside under this screen’s menu. Whenever user chooses the send option,
16
message will be sent to the selected vehicle. (Solit&Zebra Company has requested this
option to be inactive currently).
3.1.8 Setting the Data Sending Frequency
The option of setting data sending frequency of any vehicle is offered on the
“Commands” Screen. By selecting this option, a set of radio boxes which the current
data sending frequency is selected is shown. User can increase and decrease the
frequency by selecting one the values shown. The time intervals are in minutes. (This
option is inactive currently)
3.1.9 How to Control Vehicle
Controlling the selected vehicle can be done by using the “Vehicle Control”
screen which can be selected through “Commands” screen. Vehicle controlling options
are shown on this screen. Controlling options are stopping the engine, turning the
flashes off/on, and locking the doors. (This option is inactive currently)
3.1.9.1 Stop the Engine
Whenever the option “Stop the Vehicle” is selected from the “Vehicle Control”
screen the engine of the vehicle will immediately be stopped. (This option is inactive
currently)
3.1.9.2 Turn the Flashes On/Off
Whenever the option “Turn the Flashes on” or “Turn the Flashers off” is selected
from the “Vehicle Control” screen the flashers will be turned on or turned off. (This
option is inactive currently)
3.1.9.3 Lock / Unlock the Doors
Whenever the option “Lock/Unlock the door” is selected from the “Vehicle
Control” screen the doors of the vehicle will be locked/Unlocked. (This option is
inactive currently)
3.1.10 Viewing a Vehicle on the Map
Viewing a vehicle option will be offered in menu of the “List of Vehicles” screen,
“Vehicle Details” screen, and “Commands” screen. After selection of this option the
selected vehicle will be shown on the map as a star gif.
17
3.2 Nonfunctional Requirements
3.2.1 Usability
 Simple to navigate: Reaching
a desired screen from the current screen should be
done by 2-4 selections. Navigation simplicity is provided by inserting necessary
links related to screens. There are also back commands that provide user to go
back easy. Back option is handled in a manner that prevent user from being lost
during navigation.
 Error Handling:
MobitrackX should be capable of recovering from all the
crucial errors which might occur throughout the navigation over the system. The
number of errors that user can do are decreased by asking user whether user is
sure when doing a task.
 Access Priority:
More used services should be reached easier and quicker than
the less used services. The services that a user will use more are near to
application start screen. User doesn’t have to navigate more than 2 screens for
more used services. For instance tracking the vehicle on the map or seeing
vehicle details are reached from first screen of the application after login.
 Multipaths to important features: Some
important services should be reached via
more than one way. There are multipaths for services that are used more. The
services like map or vehicle list are reached from more than one screen.
3.2.2 Reliability
 Conditional Continuity:
Unless the GSM signal strength is zero all of our
services should work properly. MobitrackX application will serve unless signal
strength is zero.
 Absolute Continuity:
If the GSM signal is broken during any operation, our
application should be suspended instead of being stopped. Whenever the signal
is available again the operation should resume. MobitrackX application will
continue communicating with Mobitrack servers after signal cuts. User doesn’t
have to restart the application.
18
3.2.3 Performance
 Short response time: The data
flow between the pairs; mobile phone – GIS server
and mobile phone – Mobitrack server should be limited to some amount of data
so that the application can respond in 2-5 seconds even in any bad conditions
like low GSM signal strength and server overloads. MobitrackX application
retrieves only the data is needed. For instance vehicle list will be saved to
mobile phone memory after first login. So in later uses user doesn’t have to redownload all vehicles information. User will only retrieve information for the
vehicle selected. This will provide short response time and low GPRS charge.
3.2.4 Implementation Platform
 Programming language: MobitrackX
 Development Environment:
is implemented in J2ME.
MobitrackX is implemented on a Windows PC. The
Netbeans 5.0 is used as an Integrated Development Environment (IDE). The
Netbeans Mobility Package is used to demonstrate the application on PC.
3.3 System Structure
MobitrackX running on the mobile phone is depending on the communication
links and data formats stated on the Figure 3.1. Every component of this structure will
be explained briefly.
19
Figure 3. 1 Structure of the whole system
3.3.1 Mobitrack Vehicle
MobitrackX was designed as a system of fleet tracking instead of vehicle
tracking. So every particular vehicle belonging to the company’s fleet is an active entity
in the system as it communicates with Mobitrack Server
and receives GPS signals.
GPS signals are fortunately emitted by satellites 7 days 24 hours as a public good.
In order to have these active vehicles, every particular vehicle is equipped with a
dedicated hardware. It is nothing but a microcontroller which is installed to the vehicles.
Some censors and a GPS receiver are attached to these microcontrollers. The censors
are attached to gather interior information about a vehicle. These interior information
includes speed of the vehicle, inside temperature of the vehicle, state of the engine –is
running or not, state of the flashers –is on or off, distance counter, and fuel level of the
vehicle. And the GPS receiver just receives the appropriate satellite signals and
synchronizes with the satellites in order to locate itself –the vehicle on the earth.
After gathering the interior information by censors and position information by
GPS receiver, the microcontroller transmits this information to the Mobitrack server
periodically. Position information consists of the latitude, longitude and altitude of the
vehicle and is just enough to locate the vehicle on the earth. The software running on
the microcontroller is always ready for requests coming from the Mobitrack Server
20
while sending information to it. All the data, exchanged between Mobitrack Server and
the vehicle, is transmitted through GPRS channel.
3.3.2 Mobitrack Server
Mobitrack server is the most important component of the system structure. The
key role of the server is enabling the indirect communication between the application
and the vehicle. All the communications between the pairs: Mobile Phone – Mobitrack
Server, Vehicle – Mobitrack Server are handled by the Java Servlets running on
Mobitrack Server. The Servlets of Mobitrack Server is residing in foundation package
of PCMEF package framework. This package framework will be explained in detail in
Chapter 4.
Figure 3. 2 Inside the Mobitrack Server
As mentioned before every particular vehicle in the fleet is periodically sending
information related to that vehicle. Since DBMS provides archiving, quick response,
and easy updates; all the data gathered from the vehicle, via microcontroller and
through GPRS channel, is stored in database server – MS SQL Server 2000.
Any changes regarding the settings of the microcontroller is sent to it by
Mobitrack Server.
There is no direct communication link between the MobitrackX and the vehicles.
So MobitrackX invokes dedicated Servlets to retrieve vehicle position and interior
information from the database which is periodically updated to reflect any changes on
every particular vehicle.
21
The intervening operations requested by MobitrackX are delivered to the vehicle
via Mobitrack Server as well.
3.3.3 GIS Server
GIS Server is used in our application to load up-to-date 2D maps to the mobile
phone. GIS technology has been explained in Chapter 1. Actually there are no map
images in the GIS Server, instead there is a database running on it and storing
mathematical information regarding every particular parcel on the earth. So this can be
treated as a virtual 2D map running on servers instead of just residing there.
Figure 3. 3 Cylindrical Projection Method [10]
Even though the real shape of the earth is a special sphere named geoids, how do
we get 2D maps from virtual map running on GIS Server? The server has a 2D version
of the world map which is created by Cylindrical Projection method depicted in Figure
3.3. After projection of the earth the virtual map can be treated as something like in
Figure 3.4.
22
Figure 3. 4 2D World Map
It is stated before that in order to locate an object on the earth we need to know its
latitude, longitude and altitude. While projecting the earth to a plane, every single
combination of these three information is assigned to a ( x , y ) pair representing the
coordinates of the point on the map in Figure 3.4. Number of these combinations
depends on the sensitivity of the map in the server. There is an algorithm to convert real
position parameters to 2D map parameters. Upon a position information reaches to the
Mobitrack Server from a vehicle, this algorithm is executed to calculate coordinates of
the retrieved position on the virtual map. Both the real position and corresponding map
position information are stored in the database.
So in order to retrieve a map from GIS Server, Mobitrack uses the position
information calculated and stored in Mobitrack Server. The GIS Server is finally
queried with the parameters position (x, y) and zooming scale.
CHAPTER 4
IMPLEMENTATION
23
This section of report includes implementation details of MobitrackX application.
Deduction method will be followed to explain the project; from a general overview of
the system to detailed technical features.
Firstly package structure and the relations between them will be presented with
diagrams. Then explanation will go deeper into the system by showing functionality to
learn how background system works.
4.1 PCMEF Package Framework
One of the most important characteristics of a software project is its architectural
design. That is one of the bases for the project. The healthier the design is the more
effective and efficient the system is. Moreover a good architectural design improves
understandability, maintainability, and scalability.
The way to have a good design is to have a layered structure. PCMEF is one of
them. In MobitrackX PCMEF package framework is used to implement the system in
order to satisfy mentioned effectiveness and efficiency.
4.1.1 Layers
In figure 5.1 there is an overview of PCMEF package framework.
Figure 4. 1 PCMEF Package Framework.
 Presentation Layer
The presentation layer contains classes that define GUI objects. The user of the
system will interact with the classes residing in the presentation layer. It will be shown
detailed in the following subsections, MobitrackX main class (midlet) and other user
interfaces will be in this layer.
24
 Control Layer
This layer of PCMEF handles requests from presentation layer. It consists of the
classes responsible for processing the user interactions coming from presentation layer.
 Entity package of the domain layer
Entity package has the classes enable the system to store objects retrieved from
the database or created objects to be stored in the database.
 Mediator package of the domain layer
This package includes classes that handle control layer requests. Mediator
package establish a communication channel between entity and foundation classes. It
eliminates a need for control layer classes to communicate directly with foundation
classes.
 Foundation Layer
Foundation layer provides communication with database. It handles mediator
package requests. Foundation package consists of Java Servlets running on the
Mobitrack Server.
4.1.2 PCMEF Principles
PCMEF framework defines design principles that provide understandable,
maintainable, and scalable systems.
 Downward dependency principle: Objects in higher layers depend on objects
in lower layers.
 Upward notification principle: Objects in higher layer act as subscribers.
When an object in a lower layer changes its state, it sends notification to its
subscribers.
 Neighbor communication principle: A package can only communicate directly
with its neighbor packages.
 Explicit association principle: There are explicit unidirectional associations
between classes.
 Cycle elimination principle: There are no circular dependencies between
layers, between packages, and between classes. Circular dependencies are main
obstacles to reusability.
4.2 MobitrackX Package Structure
25
MobitrackX application has presentation, control, and domain layers. As it is seen
in Figure 4.1 the classes that communicate with database are residing in Mobitrack
server. MobitrackX use these classes as foundation layer. Overall view of the system is
seen in Figure 4.2.
Figure 4. 2 MobitrackX packages
4.2.1 MobitrackX Presentation Package
Mobitrack presentation package includes graphical user interface that user
interacts with. These Java classes are MobitrackX, LoginForm, VehicleList,
CommandList,
VehicleDetailsForm,
VehicleControlList,
DataFreqForm,
and
TextBoxSMS. (Figure 4.2)
26
Figure 4. 3 MobitrackX Presentation Package
4.2.1.1 MobitrackX.java
This class is main class of our application. It is the only midlet that the application
has. MobitrackX.java has instances of some presentation and control package classes.
MobitrackX midlet implements CommandListener class but others don’t. All the
commands in the user interfaces are handled in this midlet.
A lifecycle of a midlet generally looks like init (), start (), stop () …destroy ().
 init ( ) - on initialization
 start ( ) - on resuming, as well as after initialization
 stop ( ) - on suspension
 destroy ( ) - on finalization
The corresponding set of javax.microedition.midlet.MIDlet methods are:
 on initialization - constructor
 on finalization – destroyApp ( )
27
 on suspension – pauseApp ( )
 on resuming, as well as after initialization-startApp ( ).
There are all the methods required for a complete life cycle in MobitrackX Midlet.
All except pauseApp ( ) are implemented. But pauseApp () was not required in the
concept of our application.
The other methods are implemented for interactivity between user interfaces.
These are:

void showLoginForm ( ): On initialization this method is called. An object of
LoginForm class is created in this method.

void showVehicleList ( ): After a successful login, this method is called to
retrieve vehicle information from Mobitrack server. An object of VehicleList
class is created in this method.

void showMapCanvas ( ): In this method an object of MapCanvas class is
created. This class retrieves map information related to selected vehicle.

void showTextBoxSMS ( ): An object of TextBoxSMS class is created here.

void showCommandList ( ): An object of CommandList class is created. This
class includes options for sending SMS, controlling the vehicle, and changing
the data sending frequency for vehicles.

void showVehicleControlList ( ): This method creates an object of
VehicleControlList class. The class includes some remote controls for the
vehicles.

void changeDataFreqForm ( ): An object of DataFreqForm is created. This
class enables to change data sending frequencies for vehicles.

void commandAction ( ): This is the method of CommandListener class. Since
our midlet implements this class this method is overridden here. The method
enables interactions between user interfaces by handling command actions.
4.2.1.2 Other Classes In Presentation Package
The classes LoginForm, DataFreqForm and VehicleDetailsForm extend from
Form class of javax.microedition.lcdui package. The classes VehicleList and
CommandList extend from List class of javax.microedition.lcdui package. And the class
TextBoxSMS extends from TextBox class of the same package.
28
Forms, Lists, and TextBoxes are Displayable objects which mean they can be
displayable on the screen. These classes are used directly in the user interfaces of the
system which is discussed in details in Section 4.3.
4.2.2 MobitrackX Control Package
Control package includes classes that handle requests from presentation layer and
interacts with mediator package classes. These classes are CActioner and CMapCanvas.
Figure 4. 4 MobitrackX Control package
4.2.2.1 CActioner (Figure 4.4)
CActioner class handles all requests from presentation layer except map related
requests. These are user validation and returning other vehicle information. CActioner
has an instance of Vehicle from entity package, an instance of MVehicleBroker, and
MUserBroker from mediator package.
CActioner class’ first task is to check user validation. For this purpose it sends
user name and password passed from presentation layer to MUserBroker’s
validateUser( ) method and returns the result of it to presentation layer as a Boolean
value.
The second task is to provide vehicle related information. After a successful login
presentation layer requests all information of vehicles that user has. CActioner class
retrieves vehicles’ information from MVehicleBroker residing in mediator package.
Before discussing the methods of CActioner, it would be helpful to explain how
data management works in a Midlet. Each Midlet suite which is a group of Midlets
29
within the same package has access to non-volatile memory of the device through a
class RecordStore which resides in the package javax.microedition.rms. Each Midlet
suite has a set of RecordStores associated to it and only is accessible by the Midlets
within the same suite. Each set of RecordStores can be treated as a simple database in
which each RecordStore is a simple table with only two columns and where each row
consists of a record ID, followed by a series of bytes.
Table 4. 1 RecordStore Structure
Whenever a data of bytes are added as a new record it is assigned a record id
automatically starting from one. To reach the stored data later, these IDs are used as a
reference to the stored data. Record stores are referenced by their name, which may
consist of up to 32 characters.
Figure 4. 5 J2ME Midlet and RMS interfacing
Methods in CActioner
 boolean login ( ): Returns true if user validation was successful, false otherwise.
 void logout ( ): Logs the user out by destroying the assigned session.
 int getMapX ( ): Returns mapX coordinate of selected vehicle.
 int getMapY ( ): Returns mapY coordinate of selected vehicle.
 int fillVehicles ( ): This method checks whether a RecordStore has ever been
created for the current user which indicates there are some information available
30
offline. If there is information available in the device’s nonvolatile memory then
the vector of vehicles is filled with this information without connecting to the
server. Otherwise the control of execution is passed to the refreshVehicleList ( )
method. The number of vehicles which user has is returned.
 int refreshVehicleList ( ): This method is invoked whenever there is no offline
information available. So an http connection with a proper Servlet is initiated
through the instance of MVehicleBroker class. The vector of vehicles is filled
with these online information and the control of execution is passed to the
storeVehicles () method. The number of vehicles which user has is returned.
 void storeVehicles ( ): New RecordStore is created with the name of the current
user and filled with the static information of each vehicle. Static information
includes information which are less likely changed frequently such as the nick
name of the vehicle, name of the driver, license plate number, and unitId which
is the private key for a vehicle in the database.
 String [ ] getVehicleSummaryByIndex ( ): This method takes index of a
vehicle and returns the vehicle related static information as a string array.
 String [ ] getSingleVehicleDetails ( ): Returns detailed information related to a
vehicle. This includes dynamic information such as map coordinates and address
of the vehicle.
4.2.2.2 CMapCanvas (Figure 4.4)
CMapCanvas class resides in the control package. Using the MMapBroker class
in the mediator package, it is responsible for retrieving an appropriate map depending
on the vehicle selected in MobitrackX. Using the position information gathered through
CActioner, it makes a map image ready to display in MobitrackX.java. CMapCanvas
extends from the class Canvas residing in the J2ME package javax.microedition.lcdui.
Canvas is a low level displayable class which has access to the information about
hardware of a mobile phone such as screen width and height.
An instance of this class is created once in MobitrackX.java and used throughout
the execution of the application. It is to display a map and a single vehicle on it.
31
Methods in CMapCanvas

void setVehicle ( ): Throughout the execution of the program many of the
vehicles may need to be displayed on map. With this method the current vehicle
to be displayed can be changed.

void setZoom ( ): This method is to change the zooming scale of the current
map on the screen. Possible zooming scales are stored as final array of integers.

void zoomIn ( ): This method allows changing the zooming scale without
specifying a scale. Instead, zooming scale is set to next possible smaller scale
automatically.

void zoomOut ( ): The next possible greater scale is set by this function which
results a less detailed map with greater real area shown.

void retrieveMap ( ): After changing any information regarding the current
map, this method should be invoked to reflect changes on to the screen as a new
map image.

void moveEast ( ), void moveWest ( ): Whenever any of these methods are
called; a new map image is retrieved which is shifted, as much as one third of
the image width, to the proper direction.

void moveNorth ( ), void moveSouth ( ): Whenever any of these methods are
called; a new map image is retrieved which is shifted to the proper direction as
much as one third of the height of the map.

void adjustVehicleToCenter ( ): While moving around the map and changing
the zooming scale a vehicle may happen to be out of the range of the screen.
This method retrieves a new map image which has the same zooming scale with
current one, but coordinates will be changed so that the vehicle appears in the
center of the screen.
4.2.3 MobitrackX Mediator Package
Mediator package includes classes provide communication between Control
package classes and foundation package classes. As we talked about before in
Mobitrack application foundation package classes are not implemented. Mobitrack
server is assumed as foundation package and servlets in the server are assumed
foundation package classes. The only difference of this structure from PCMEF structure
32
is that, here mediator classes don’t have foundation package class instances. Instead of
that mediator class objects communicate with servlets residing in server and retrieve
XML data and manipulate it. Mediator package classes are MUserBroker,
MVehicleBroker, and MMapBroker. (Figure 4.6)
Figure 4. 6 MobitrackX mediator package.
4.2.3.1 kXML Package
In the classes MVehicleBrooker and MUserBrooker, XML parsing was required.
As a program running on a mobile phone MobitrackX has limited resources such as
memory, screen size and processor. Considering the limited processor and limited
memory of a mobile phone, the J2SE classes which enable XML parsing are not
included in the standard libraries of J2ME by its developers.
The kXML parser was used whenever XML parsing was required. kXML is a
small pull-parser which combines some of the advantages of SAX and DOM while
consuming less resources of the device it is running on. It is specifically designed for
constrained environments such as Applets, Personal Java or MIDP devices.
4.2.3.2 MMapBroker (Figure 4.6)
MMapBroker is responsible for communication between the CMapCanvas and
GIS Server. Information which is required to retrieve a map image is passed to this class
from CMapCanvas.
33
Method of MMapBroker
 getImage ( ): This method initiates an http connection with GIS Server through
GetImage.aspx which returns an appropriate map when invoked. The returned
image is then read byte-by-byte; a local copy of the image is created and returned.
4.2.3.3 MUserBroker (Figure 4.6)
This class handles the Login related communication between the application and
the database through an appropriate Servlet running on the Mobitrack Server, residing
in the foundation package.
Methods of MUserBroker
 boolean validateUser ( ): This method initiates an http connection with the
Servlet Login.java. Username and password information, which is required to
validate a user of the system, is passed to this method from upper layers. The
Servlet is then invoked with the appropriate data and returns an XML file as
response to this invocation. By streaming the returned file byte by byte local
copy of the file and an kXML parser are created, and the control of execution is
passed to the traverse( ) method. A sample xml file returned after a successful
login is given in Figure 4.7. The text in the tag <success> indicates whether the
validation was successful or not. This method returns true if the validation was
successful and false otherwise.
Figure 4. 7 Returned XML After a Successful Login
34
 traverseUnitInfoXml ( ) : This method traverses through the xml tags to set
required variables.
4.2.3.4 MVehicleBroker (Figure 4.6)
This class handles the Fleet related communication between the application and
the database through an appropriate Servlet running on the Mobitrack Server, residing
in the foundation package.
Methods of MVehicleBroker
 fillVehiclesInfo ( ): This method initiates an http connection with the Servlet
GetUnitInfo.java. Session information, which is required to retrieve Fleet
information, is passed to this method from upper layers. The Servlet is then
invoked with this session id and returns an XML file as response to this
invocation. A local copy of the file and a kXML parser are created, and the
control of execution is passed to the traverse ( ) method. A sample xml file
returned by the Servlet and consisting of two vehicles is given in Figure 4.7. The
tag <row> indicates a particular vehicle and the attributes are the information
related to that vehicle. This method returns a Vector consisting of the vehicles
on the fleet with the necessary information filled.
 getSingleVehicle ( ): Depending on the unitId of the vehicle passed to this
method, the Servlet GetUnitInfoMobile.java is invoked. After traversing through
the returned XML with traverseSingleUnitInfoXml method, a new Vehicle
object, with the required fields are filled, is created and returned.
Figure 4. 8 Returned XML Consisting of Two Vehicles
35
 traverseUnitInfoXml ( ): This method traverses through the xml tags to set
required variables of every vehicle.
4.2.4 MobitrackX Foundation Package
Foundation package of PCMEF structure stores classes communicating with
database. The database and the Servlets are running on the same server –Mobitrack
Server. MobitrackX mediator package classes communicate with database via these
Servlets. The Servlets that mediator classes get contact with are Login.java,
Logout.java, and GetUnitInfo.java.
Each Servlet can be treated as a web method or web service, they are always
running on the web to respond queries coming from any application. They are accepting
some parameters and return a data varying from primitive data types to images. All the
Servlets are working with get methods which refer sending required parameters within
the URL of the server. Each Servlet is briefly explained below.
4.2.4.1 Login.java
This Servlet can be invoked with a URL similar to the one below.
http://212.154.33.46/servlet/Login?username=hasan&password=pass&session=A
LONGSETOFCHARACTERSGOESHERE
As response to this request Servlet sends a data in XML format indicating whether
the login was successful or not, by checking the proper fields in the database. Figure 4.7
shows a sample XML data returned by this Servlet after a successful login.
4.2.4.2 Logout.java
This Servlet can be invoked with a URL similar to the one below:
http://212.154.33.46/servlet/Logout?username=hasan&password=pass&session=
ALONGSETOFCHARACTERSGOESHERE
After the Servlet is invoked with the given URL, the session which is used in
communication between the application and the Servlet is destroyed. A proper data in
XML is returned indicating the success of the Logout process.
4.2.4.3 GetUnitInfo.java
This Servlet can be invoked with a URL similar to the one given below:
http://212.154.33.46/servlet/GetUnitInfo?mapName=BasarSoft&unitId=1&sid=hasan|ALONGSETOFCHARACTERSGOESHERE
36
Whenever the Servlet is invoked with the given URL, it responds with an XML
data including the information of the vehicles that “hasan” has rights to track. If unitId
in the URL is set to -1 all the vehicles that “hasan” has rights to track is returned within
an XML data. If it is set to a non-zero value, the vehicle with the indicated unitId is
returned within an XML data. A sample XML data returned by this Servlet is given in
Figure 4.8.
Figure 4. 9 Sequence Diagram for Login and VehicleList
To have an idea about how the instances of the classes interact with each other
throughout the execution of the program, a sequence diagram which illustrates actions
occurs upon a login request is shown in Figure 4.9.
37
4.3 User Interface
4.3.1 Login Form
It has textboxes for username and password that are required for authentication.
Cancel and Submit options are available on the screen of this form.
Figure 4.10 Screenshot of Vehicle List and Vehicle Details
4.3.2 Vehicle List
The available operations on this screen are; viewing details of selected vehicle,
viewing selected vehicle on the map, going to Commands screen for selected vehicle
and refreshing the list. The information shown on the Vehicle List is retrieved from
device’s non-volatile memory if any offline data is available. If the user made changes,
such as adding a new vehicle, removing an existing vehicle or changing the driver of
any vehicle, on the Fleet bound to his/her account; then this offline information will not
reflect those changes. As being aware of these changes user can select Refresh List
option to replace persistent data on the mobile phone with those up-to-date.
4.3.3 Vehicle Details
Vehicle Details can be seen on the screen as an instance of the VehicleDetails
class. It retrieves and displays dynamic data such as address and speed of the selected
vehicle.
38
Figure 4. 11 Screenshot of Commands and Vehicle Control
4.3.4 Commands
Available Commands for a vehicle is displayed on the screen as an instance of the
CommandList class.
4.3.5 Vehicle Control
The instance of VehicleControlList class is set to screen. Available vehicle
intervening options are displayed. These operations are running/stopping the engine,
turning on/off the flashes, and locking/unlocking the doors depending on their current
state.
4.3.6 Send SMS
An instance of TextBoxSMS class is set to screen which extends from TextBox of
javax.microedition.lcdui package. Sending the written message, clearing the message
and turning back to Vehicle List screen are the commands available here.
39
Figure 4. 12 Screenshot of Send SMS and Change Data Frequency
4.3.7 Change Data Frequency
Data frequency is the time between two consequent data transmission from
vehicle to the Mobitrack Server. This frequency can be updated through the instance of
DataFreqForm class which extends Form from javax.microedition.lcdui package.
Figure 4. 13 Country and Region View Of The Map Screen
40
4.3.8 Map Screen
Map screen is the most important and powerful feature of MobitrackX. Every
kind of required operation regarding navigation on a map is provided with the system.
Whenever the map is requested for a specific vehicle, a default map will be
displayed in which the vehicle can be seen within the whole country it is currently in.
Default map is retrieved so that the vehicle appears in the center of the map. In addition
to the map address, nickname, and speed of the selected vehicle is displayed at the
bottom of the screen.
The active keypad buttons for map operations are; up-arrow, down-arrow, and the
number buttons 2, 4, 6, 8, and 5. A user can move to west, east, north, and south by
pressing the number buttons 2, 4, 6, and 8, respectively. Moving horizontally generates
a new map shifted to the proper direction as much as one third of the width of the area
assigned to map image. Moving vertically generates a new map shifted to the proper
direction as much as one third of the height of the area assigned to map image.
In the requirement analysis phase of the MobitrackX, it was concluded that a user
needs changing the zoom more often then he/she needs moving around the map. So
zooming options are assigned to up and down arrow keys which can be reached more
quickly than any other buttons on the keypad. Pressing the down-arrow button and the
up arrow-button generates a map with the next possible smaller zooming scale, and a
map with the next possible greater zooming scale, respectively. If the current zooming
scale is the biggest possible scale or the smallest possible scale, no new map is
generated.
A user might want to view the vehicle on the street detailed map just after the
default map. We have quick menu item for these kinds of direct operations. A map
showing the vehicle within the street, region, city, and country it is now in can be
quickly retrieved using the menu options: Show In Country, Show In City, Show In
Region, and Show In Street. Instead of continuously pushing the zoom-in or zoom-out
buttons to retrieve a map with intended zooming scale; any of these options, which bypasses the zooming scales between the current zooming scale and intended zooming
scale, can be used.
And number button 5 can be used to justify the vehicle in the center of the map.
While moving around the map and changing the zooming scale a vehicle may happen to
be out of the range of the screen. This operation results a new map which has the same
41
zooming scale with current one, but coordinates will be changed so that the vehicle
appears in the center of the screen.
In the menu of the screen, a help selection is ready for reminding which functions
are assigned to which keypad buttons. In addition to the mentioned options, using the
menu user can exit from the whole application or display the list of the all vehicles.
42
CHAPTER 5
CONCLUSION
To summarize; our project is a vehicle tracking application that runs on java
supported mobile phones. Our application uses existing Mobitrack infrastructure by
connecting servers through GPRS technology. The application serve basic position
related services in a cheap, user friendly, and fast way. All existing Mobitrack users are
able to use this mobile phone service after installing the application to their mobile
phones. After authentication steps, user will benefit those services like retrieving
address information or map that shows the location of the vehicle and etc.
A future work as an extension to the current MobitrackX system would be
including some more functionality to serve the program as a map guide. Address
searching capability is one of these possible extensions. Getting the search criteria from
user the most relevant map should be displayed for his/her convenience.
43
REFERENCES
[1] Bruegge, B. and Dutoit, A. H., Object-Oriented Software Engineering Using UML,
Patterns, and Java, Pearson, 2004
[2] Maciaszek L.A. and Liong B.L. Practical Software Engineering , Addison Wesley,
Harlow England, 2005
[3] Keogh, J., J2ME: The Complete Reference, McGraw-Hill, California, 2003
[4] Alan Sicher, Communications Product Planning Manager Randall Heaton, Product
Marketing Senior Consultant, GPRS technology Overview
http://www.dell.com/downloads/global/vectors/2002_gprs_overview.pdf, 2002
[5] Ghosh, Soma, Add data storage capacities to your MIDlet apps, 1 May 2002
http://www-128.ibm.com/developerworks/library/wi-rms/
[6] Muchow John, Working with the RMS,16 Oct 2001
http://www.microdevnet.com/articles/techtalk/rms
[7] Ghosh, Soma, Add XML parsing to your J2ME applications, 16 Sep 2003
http://www-128.ibm.com/developerworks/library/wi-rms/
[8] Mahmoud, Qusay, MIDP Network Programming using HTTP and the Connection
Framework, Nov 2000
http://developers.sun.com/techtopics/mobility/midp/articles/network/
[9] Mahmoud, Qusay, MIDP Inter-Communication with CGI and Servlets, Feb 2001
http://developers.sun.com/techtopics/mobility/midp/articles/servlets/index.html
[10] H. Dana, Peter, Global Positioning System Overview, Sep 1994, Revised in May
2000
http://www.colorado.edu/geography/gcraft/notes/gps/gps_f.html
44