Tis

Transport Information System 2
008
Table of Contents
1. BACKGROUND........................................................................................................................6
2. PROBLEM STATEMENT........................................................................................................9
3. INTRODUCTION....................................................................................................................11
3.1 SYSTEM OVERVIEW:.................................................................................................................11
3.2 AIMS AND OBJECTIVES:.............................................................................................................11
3.3 PROJECT SCOPE........................................................................................................................11
3.4 SYSTEM DESCRIPTION:..............................................................................................................12
3.5 ACTUAL DESIGN:.....................................................................................................................12
3.6 UNIVERSITY REQUIREMENT:.......................................................................................................13
3.7 SYSTEM MODULE:....................................................................................................................14
3.8 SYSTEM COMPONENTS:.............................................................................................................16
3.9 POTENTIAL CLIENTS:................................................................................................................16
4. LITERATURE REVIEW........................................................................................................18
4.1 GSM NETWORK......................................................................................................................18
4.1.1 History of GSM.............................................................................................................18

4.1.2 Services provided by GSM............................................................................................19
4.1.3 Architecture of the GSM network.................................................................................20
21
4.1.4 Mobile Station..............................................................................................................21
4.1.5 Network Subsystem.......................................................................................................22
4.1.6 Radio link aspects.........................................................................................................22
4.1.7 Network aspects............................................................................................................23
4.2 GLOBAL POSITIONING SYSTEM (GPS)..........................................................................................24
4.2.1 GPS...............................................................................................................................24
4.2.2 GPS Receivers..............................................................................................................26
4.2.3 NMEA Data..................................................................................................................27
5. ANALYSIS AND DESIGN......................................................................................................30
008
5.1 ACTOR USE CASE DIAGRAM:....................................................................................................30
5.2 ANALYSIS................................................................................................................................32
5.3 DESIGN:..................................................................................................................................59
6. IMPLEMENTATION..............................................................................................................83
6.1 APPLICATION INTERFACES:.........................................................................................................83
6.2 USER SERVICE:........................................................................................................................99
6.3 DEVICE SERVICE:...................................................................................................................100
6.3.1 TeltonikaFM4100........................................................................................................101
7. DATABASE IMPLEMENTATION......................................................................................104
7.1.1 Entity Relationship diagrams.....................................................................................104
8. TESTING................................................................................................................................107
8.1 TESTING AREAS.....................................................................................................................107
8.2 TESTING PHASES.....................................................................................................................107
8.2.1 Phase 1.......................................................................................................................107

8.2.2 Phase 2.......................................................................................................................108
8.2.3 Phase 3.......................................................................................................................109
9. RESULTS................................................................................................................................112
10. DISCUSSION.......................................................................................................................119
11. CONCLUSION.....................................................................................................................121
12. FUTURE WORK.................................................................................................................123
13. REFERENCES.....................................................................................................................125
13.1 WEB REFERENCES................................................................................................................125
2 of 125
008
List of Figures
FIG. 3.1 SYSTEM VIEW...........................................................................................................13

FIG. 3.2 UPDATED SYSTEM VIEW.......................................................................................14
FIG. 4.3 GENERAL ARCHITECTURE OF A GSM NETWORK [1]..................................21
FIG. 4.4 ORGANIZATION OF BURSTS, TDMA FRAMES, AND MULTI FRAMES FOR
SPEECH AND DATA [1].............................................................................................................23
FIG. 4.5 SIGNALING PROTOCOL STRUCTURE IN GSM [1]..........................................24
FIG. 4.6 HOW GPS WORKS [2]...............................................................................................25
FIG. 4.7 GPS SATELLITE [3]...................................................................................................26
FIG. 4.8 GPS SATELLITE CONSTELLATION [3]...............................................................27
FIG. 5.9 USE CASE COMMUTER..........................................................................................31
FIG. 5.10 USE CASE SYSTEM ADMINISTRATOR.............................................................32
FIG. 6.11 ADD A NEW BUS GROUP.......................................................................................83
FIG. 6.12 ADD A NEW BUS......................................................................................................84
FIG. 6.13 ADD A NEW ROUTE................................................................................................84
FIG. 6.14 ADD NEW STOPS AND THEIR LOCATIONS FOR ROUTE UP......................85
FIG. 6.15 ADD NEW STOPS AND THEIR LOCATIONS FOR ROUTE DOWN..............86
FIG. 6.16 ADD A NEW DEVICE..............................................................................................86
FIG. 6.17 ADD A NEW DRIVER AND ITS INFORMATION...............................................87
FIG. 6.18 ADD STOPS FOR THE ROUTE UP.......................................................................88
FIG. 6.19 ADD STOPS FOR THE ROUTE DOWN...............................................................89
FIG. 6.20 EDIT THE DEVICE NUMBER...............................................................................89
FIG. 6.21 EDIT THE BUS NAME............................................................................................90
FIG. 6.22 EDIT THE ROUTE NAME......................................................................................90
FIG. 6.23 EDIT THE STOP IN ROUTE UP............................................................................91
FIG. 6.24 EDIT THE STOP IN ROUTE DOWN.....................................................................92
FIG. 6.25 EDIT REGISTRATION NUMBER.........................................................................93
FIG. 6.26 EDIT STOP LOCATION FOR ROUTE DOWN....................................................93
3 of 125
008
FIG. 6.27 EDIT STOP LOCATION FOR ROUTE UP...........................................................94

FIG. 6.28 DELETE THE BUS THAT HAS LEFT THE COMPANY....................................95
FIG. 6.29 DELETE THE DRIVER INFORMATION.............................................................95
FIG. 6.30 DELETE THE DEVICE THAT HAS BEEN DEFECTED...................................96
FIG. 6.31 TERMINATE THE BUS INSTANCE OF THE BUS THAT HAS REACHED
ITS DESTINATION....................................................................................................................96
FIG. 6.32 TRACK THE CURRENT LOCATION OF THE BUSS WITH RESPECT TO
THE BUS NAME.........................................................................................................................97
FIG. 6.33 CREATE A NEW INSTANCE OF THE BUS.........................................................98
FIG. 6.34 BUS INSTANCE DETAIL........................................................................................98
FIG. 6.35 TELTONIKAFM4100 [5]........................................................................................102
FIG. 7.36 SYSTEM ENTITY RELATIONSHIP DIAGRAM...............................................105
FIG. 9.37 WRONG STOP NAME...........................................................................................112
FIG. 9.38 REPLY OF WRONG STOP NAME......................................................................113
FIG. 9.39 WRONG ROUTE....................................................................................................114
FIG. 9.40 REPLY OF WRONG ROUTE................................................................................114
FIG. 9.41 WRONG BUS NAME..............................................................................................115
FIG. 9.42 REPLY WRONG BUS NAME................................................................................116
FIG. 9.43 CORRECT FORMAT.............................................................................................117
FIG. 9.44 CORRECT REPLY.................................................................................................117
4 of 125
008
CHAPTER
Background
1
5 of 125
008
1. Background
Many vehicle tracker companies are currently working in Pakistan. They are using some
dedicated software applications for manipulating GPS coordinates. But no one is working on
application that gives the SMS interface for real time query. The field in which we worked is
somehow different because we provide the SMS interface for tracking application.
When we talk about GPS history in Pakistan it is widely used by the vehicle tracker companies,
GPS-GSM device is installed in the vehicle ,it simply send data to the server about the current
location of the vehicle ,the particular data is uploaded by using the GPRS facility of GSM
modem. Some companies are also using SMS alerts to track the particular vehicle. Data that is
received by GPRS or in SMS is basically the Longitude & Latitude of a particular instance, these
longitudes & latitudes are then mapped on real map, by using this strategy vehicle’s current
location and speed is investigated. The major job that is performed by this type of companies is
to make sure that their registered vehicle should be transported within defined boundaries. In
case of route violation they will track the vehicle and inform the law enforcement agencies about
the current location of the vehicle.
Some part of our project task is very much similar with the job of any tracker company. On the
other hand we have to maintain the current location of each bus in database. Secondly we have to
select a communication technique that is accessible for the majority of the citizens of Karachi.
GSM mobile phone is the first option for updating a commuter. Mobile phone users increased
rapidly in last few years and today that trend is growing in the same fashion. The major reason
6 of 125
008
behind this development is the portability and exponential decrease in the cost of cell phones. On
the other hand the GSM service providers are also increasing rapidly in Pakistan. The average
cost of the SMS service provided by these companies is reduced to 20 or 10 paisa per SMS. So
SMS service is the best option available today for updating the commuter any where and any
time.
Initially the idea was to build a distributed web application, because the bus starts from two
locations and the data of both the busses should be maintained.
This idea was turned down because of the cost of the project. If it would have been distributed
then the company will have to appoint two computer literate people on both ends and also an
extra personal computer.
7 of 125
008
CHAPTER
Problem Statement
2
8 of 125
008
2. Problem Statement
Majority of population in Karachi travels in public transport, their trouble starts when they reach
at bus stop and wait for the arrival their desired bus. Passengers have to spend their precious time
at bus stop without any shelter. There is no specific arrival time of these public busses.
Now if there is some way that these passengers are get informed by the arrival time of that
particular bus they can save their valuable time as well as their trouble is reduced.
9 of 125
008
CHAPTER
Introduction
3
10 of 125
008
3. Introduction
In this chapter we have discussed design, key constituents, requirement specification, and
performance specification and block diagram of transport information system.
3.1 System Overview:
To develop a system that informs a commuter about the arrival time of his/her desired bus
(Public Transport) on their cell phones screens.
3.2 Aims and Objectives:
To make information system to facilitate public transport passenger especially in Karachi by
informing the commuters about arrival of their desired bus remotely. We can decrease much of
their trouble by updating them with the bus arrival time on their stop. For achieving that goal we
have to select such a communication technique that is cheap as well as in access of every single
person.
3.3 Project Scope
The idea of the project is about providing transport operators and passengers an attractive
alternate of commuting in the city in their personal vehicles.
The project will track and provide availability of public transport information to the commuters
easily accessible on the screens of their cell phones.
11 of 125
008
3.4 System Description:
Transport Information System is a vehicle tracking system having interface with GSM networks.
A GPS device is installed in the vehicle to track the vehicle location. This system facilitates the
commuters by sending approximate time that a bus needs to get to the stop required by the
commuter on the screens of their cell phones. The commuter will send a SMS in the following
format <Bus Name> <Stop Name > <up/down>. The commuter will be updated about the
approximate timing of the bus which he/she has queried.
3.5 Actual Design:
The complete transport information system comprises of GPS receiver that is installed in the bus.
The GPS receiver data that is simply a sentence carrying longitude & latitude of a particular
location is uploaded on a real IP by using GPRS technology. Database is continuously updated
by current location of the particular bus.
On the other hand commuters send SMS that also propagate through GSM network and received
on GMSM modem installed on server. Complete system overview of transport information
system is described in Fig 3.1.
1. Commuter send an inquiry SMS to server.
2. SMS received at server through GSM network.
3. Server is continuously updated by the current location of each bus on route.
4. Time calculation is performed at server end with respect to the current SMS received.
12 of 125
008
5. Commuter is informed by the arrival time of his/her desired bus by reply SMS.
Fig. 3.1 System view
3.6 University Requirement:
After the project defense presentation scope of transport information system is revised, according
to new scope we have to focus on system design defined in Fig 3.2.
Basically the work on GPS receiver and its communication with the server is omitted. University
provided a dedicated device FM4100 that has built-in GPS receiver & GSM modem available on
a single package. By using that device we able to upload the current location of each bus on a
13 of 125
008
real IP by using the GPRS facility of respective GSM modem. Database & application design is
our major task; we also have to work on SMS service provided by our application.
Fig. 3.2 Updated System View
3.7 System Module:
The system comprises of three modules
1. SMS
2. Database
14 of 125
008
3. GPS
A GSM modem along with a GPS module will be installed in each bus which will send the exact
coordinates of the bus to the internet after every 10 seconds. That data will be downloaded by a
windows service to the database server.
The SMS that the user will send will be received by the OZEKI Message Server in “.MSG”
format. The file will be saved in a folder “SMS IN”. This file will then be read by our application
and parse the message and apply the following checks:
1. If the bus name exists or not.
2. If it exists, then does the required stop belong to that bus route?
3. If the stop does not exist, then a SMS will be sent back to the user indicating that the stop
does not belongs to the route.
4. If it exists in the route then the system checks all the buses in that particular route then the
bus that is closest to the queried stop is checked first.
5. The time to reach of the bus whose next stop corresponds to the stop name sent by the user through
the SMS is sent back to the user.
6. If there is not any bus exist whose next stop corresponds to the stop name sent by the user then the
system searches for a bus on the stop previous to that. It continues searching until it finds a bus on a
stop. The system then adds up the time for the bus to reach each stop up to the required stop.
15 of 125
008
The reply will be sent via a text file to the “SMS OUT” folder. The file will have the same name
as the user’s cell phone number. The folder is maintained by the OZEKI message server. The
server sends the file as a SMS to the user.
3.8 System Components:
The system consists of the following components
1. GSM Modem
2. GPS Module
3. Real IP
3.9 Potential Clients:
1. Busses like Metro Bus Service and UTS
2. National Logistic Cell
16 of 125
008
CHAPTER
Literature Review
4
17 of 125
008
4. Literature Review
In this chapter we mentioned the literature review that we studied before the design and
implementation of the project, the respective material has truly help a lot in understanding key
constituent design & execution of transport information system.
4.1 GSM Network
4.1.1History of GSM
In the early 1980s, analog cellular telephone systems were achieving rapid expansion in Europe,
particularly in Scandinavia and the United Kingdom, but also in France and Germany. Each
country developed its own system, which was unable to coexist with everyone else's in system
and processes. This was an unattractive circumstance, because the mobile equipment was
bounded to operation within national boundaries, the mobile phones users can communicate only
within a selected system boundary.
The Europeans understand this early on, and in 1982 the Conference of European Posts and
Telegraphs (CEPT) formed a study group called the Groupe Spécial Mobile (GSM) to study and
develop a pan-European public land mobile system. The proposed system had to meet certain
criteria:
1. Good subjective speech quality
2. Low terminal and service cost
3. Support for international roaming
18 of 125
008
4. Ability to support handheld terminals
5. Support for range of new services and facilities
6. Spectral efficiency
7. ISDN compatibility
4.1.2Services provided by GSM
From the very first day, the pioneers of GSM wanted ISDN compatibility with respect to services
that offered by GSM. However, radio transmission limitations, in terms of bandwidth and cost,
do not allow the standard ISDN B-channel bit rate of 64 kbps to be practically achieved.
Using the ITU-T definitions, telecommunication services can be composed of bearer services,
tele services, and additional services. The most basic tele service supported by GSM is
telephony. As with all other communications, speech is digitally encoded and transmitted through
the GSM network as a digital stream.
A wide range of data services is offered by GSM. GSM users can send and receive data, at rates
up to 9600 bps, to users on POTS (Plain Old Telephone Service), ISDN, Packet Switched Public
Data Networks, and Circuit Switched Public Data Networks using a variety of access methods
and protocols. Since GSM is a digital network, a modem is not required between the user and
GSM network, although an audio modem is required inside the GSM network to inter work with
POTS.A unique feature of GSM, not found in older analog systems, is the Short Message Service
(SMS). SMS is a bidirectional service for short alphanumeric (up to 160 bytes) messages. These
digital messages are transported in a store-and-forward approach. For point-to-point SMS, a
message can be sent or received to another subscriber, and an acknowledgement of the reception
19 of 125
008
of the SMS is received by the sender that particular SMS is received by the destination or
receiver. SMS can also be used in a cell-broadcast mode; this type of service is used when we
have to send same massage to multiple users like news broadcast. SMS can also be stored in the
SIM card for later retrieval [1].
4.1.3Architecture of the GSM network
A GSM network is composed of several useful units, whose functions and interfaces are
specified. Fig 4.1 shows the layout of a generic GSM network. The GSM network can be divided
into three broad parts. The Mobile Station is carried by the subscriber. The Base Station
Subsystem controls the radio link with the Mobile Station. The Network Subsystem, the main
part of which is the Mobile services Switching Center (MSC), executes the switching of calls
between the multiple mobile users, and between mobile and fixed network users. The MSC also
holds the mobility management operations. Not shown is the process and Maintenance Center,
which manages the proper operation and setup of the network. The Mobile Station and the Base
Station Subsystem communicate across the Um interface, also known as the air interface or radio
link. The Base Station Subsystem communicates with the Mobile services Switching Center
across the A interface [1].
20 of 125
008
Fig. 4.3 General architecture of a GSM network [1]
4.1.4Mobile Station
The mobile station (MS) consists of the mobile tools (the terminal) and a smart card called the
Subscriber Identity Module (SIM). The SIM provides personal mobility, so that the user can have
access to subscribed services irrespective of a specific terminal. By inserting the SIM card into
another GSM terminal, the user is able to receive calls at that terminal, make calls from that
terminal, and receive other subscribed services.
The mobile equipment is uniquely identified by the International Mobile Equipment Identity
(IMEI). The SIM card contains the International Mobile Subscriber Identity (IMSI) used to
identify the subscriber to the system, a secret key for authentication, and other information. The
21 of 125
008
IMEI and the IMSI are independent, thereby allowing personal mobility. The SIM card may be
protected against unauthorized use by a password or personal identity number [1].
4.1.5Network Subsystem
The central part of the Network Subsystem is the Mobile services Switching Center (MSC). It
acts like a normal switching node of the PSTN or ISDN, as well as give all the functionality
needed to handle a mobile subscriber, such as registration, authentication, location updating,
handovers, and call routing to a roaming subscriber. These services are provided in combination
with several functional entities, which together form the Network Subsystem [1].
4.1.6Radio link aspects
The International Telecommunication Union (ITU), which manages the international allocation
of radio spectrum, allocated the bands 890-915 MHz for the uplink; mobile station to base
station, and 935-960 MHz for the downlink ;base station to mobile station, for mobile networks
in Europe. Since this range was already being used in the early 1980s by the analog systems of
the day, the CEPT had the foresight to reserve the top 10 MHz of each band for the GSM
network that was still being developed. Ultimately, GSM will be assigned the whole 2x25 MHz
bandwidth [1].
4.1.6.1 Traffic channels
A traffic channel (TCH) is used to carry speech and data traffic. Traffic channels are defined
using a 26-frame multiform, or group of 26 TDMA frames. The length of a 26-frame multiform
is 120 ms, which is how the length of a burst period is defined (120 ms divided by 26 frames
22 of 125
008
divided by 8 burst periods per frame). Out of the 26 frames, 24 are used for traffic, 1 is used for
the Slow Associated Control Channel (SACCH) and 1 is currently unused as mentioned in Fig
4.2. TCHs for the uplink and downlink are separated in time by 3 burst periods, so that the
mobile station does not have to transmit and receive simultaneously, thus simplifying the
electronics [1].
Fig. 4.4 Organization of bursts, TDMA frames, and multi frames for speech and data [1]
4.1.7Network aspects
Ensuring the communication of voice or data of a given quality over the radio link is only part of
the role of a cellular mobile network. A GSM mobile can faultlessly wander nationally and
internationally, which requires that registration, authentication, call routing and location updating
functions exist and are homogeneous in GSM networks. In addition, the fact that the
23 of 125
008
geographical area covered by the network is divided into cells requires the implementation of a
handover mechanism [1]. As mentioned in Fig 4.3.
Fig. 4.5 Signaling protocol structure in GSM [1]
4.2 Global positioning system (GPS)
4.2.1GPS
The law behind GPS is the calculation of distance between the satellites and the receiver. The
satellites notify receiver exactly where they are in their orbits by broadcasting data, the receiver
on the other end uses that similar data to compute their positions. If we know our precise
distance from a satellite in space, we know we are somewhere on the surface of an imaginary
sphere with a radius equal to the distance to the satellite radius. If we know our exact distance
from two satellites, we know that we are located somewhere on the line where the two spheres
intersect. And, if we take a third and a fourth measurement from two more satellites, we can find
our location. The GPS receiver processes the satellite range measurements and produces its
position Fig 4.4.
24 of 125
008
Fig. 4.6 How GPS works [2]
GPS utilizes a method of coordinates called WGS 84, which stands for World Geodetic System
1984. It permits surveyors all around the world to generate maps, all with a common reference
frame for the lines of latitude and longitude that trace places and things all over the entire world.
Likewise, GPS uses time from the United States Naval Observatory in Washington, D.C., to
synchronize all the timing constituents of the GPS system, much like Harrison's chronometer
was synchronized to the time at Greenwich [2].
25 of 125
008
4.2.2GPS Receivers
GPS generally means a GPS receiver. The Global Positioning System (GPS) is actually a
constellation of 27 Earth-orbiting satellites (24 in operation and three backup in case one fails).
The U.S. military developed and executed this satellite network for a military navigation system,
but soon opened it everyone else. Fig 4.5 & 4.6 shows the GPS satellites hovering around earth.
Fig. 4.7 GPS satellite [3]
Each of these 3,000- to 4,000-pound solar-powered satellites float around the Earth at about
12,000 miles (19,300 km), making two complete rotations every day. The orbits are arranged so
that at anytime, anywhere on Earth, there are at least four satellites "visible" in the sky.
26 of 125
008
Fig. 4.8 GPS satellite constellation [3]
A GPS receiver's function is to locate four or more of these satellites, calculate the distance to
each one, and use this information to deduce its own location. GPS receiver formulates that data
in form of longitude and latitude respectively [3].
4.2.3NMEA Data
The National Marine Electronics Association NMEA has developed a design that defines the
interface between various pieces of marine electronic equipment. The standard allows marine
electronics to send information to computers and to other marine equipment.
GPS receiver communication is defined within this specification. Most computer programs that
provide real time position information understand and expect data to be in NMEA format. This
data includes the complete PVT (position, velocity, time) solution computed by the GPS receiver
[4].
27 of 125
008
4.2.3.1 NMEA sentence
NMEA consists of sentences, the first word of which, called a data type, defines the explanation
of the rest of the sentence. Each Data type would have its own unique interpretation and is
defined in the NMEA standard. NMEA sentences may repeat some of the same information but
will also supply new data. Whatever device or program that interpret the data can watch for the
data sentence that it is concerned and simply ignore other sentences that is doesn't care about [4].
28 of 125
008
CHAPTER
Analysis and Design
5
29 of 125
008
5. Analysis and Design
In this chapter we have discussed overall system structure, requirement capture, data handling
methods and dataflow techniques.
5.1 Actor Use Case Diagram:
Use-cases are used to capture the requirements of the customer. Through use-case modeling, the
external actors that have interest in the system are modeled along with the functionality they
require from the system (the use cases). The actors and use cases are modeled with relationships
and have communication associations with each other or are broken down into hierarchies. The
actors and use cases are described in a UML use-case diagram. Each use case is described in text,
and that specifies the requirements of the customer, what he or she expects of the system,
without considering how the functionality will be implemented. Transport information system
has two major actors which is Commuter and System administrator. The use-case diagrams are
mentioned in Fig 5.1 & 5.2.
30 of 125
008
Send sms Commuter

Initiate
Receives sms
Initiate
Fig. 5.9 Use Case Commuter
31 of 125
008
Fig. 5.10 Use Case System Administrator
5.2 Analysis
Analysis is concerned with the primary abstractions and mechanisms that are present in the
problem domain. Analysis provides the software designer with a representation of information,
function, and behavior that can be translated to data, architectural, interface, and component-
level designs.
Each analysis method has a unique point of view. However, all analysis methods are related by a
set of operational principles:
32 of 125
008
1. The information domain of a problem must be represented and understood.
2. The functions that the software is to perform must be defined.
3. The behavior of the software (as a consequence of external events) must be represented.
4. The models that depict information function and behavior must be partitioned in a manner
that uncovers detail in a layered (or hierarchical) fashion.
5. The analysis process should move from essential information toward implementation detail.
33 of 125
008
34 of 125
008
USECASE NAME: Commuter’s Query
ACTOR Commuter
DESCRIPTION: Commuter will send a SMS about the information of a

particular bus.
ACTOR ACTION SYSTEM RESPONSE
STEP 1: commuter will send an SMS about the
enquiry of the bus STEP 2 : System will first check that the bus belongs to the
particular route or not
STEP 2.1 If the bus name does not exist
STEP2.1.1 A SMS will be sent to the user that the bus does
not exist.
STEP2.2 If the bus exists then
STEP3: The stop name queried by the user will be verified

STEP 3.1 If the stop does not come in the route of the bus
STEP3.1.1 A SMS will be sent to the user that the stop does
not belong to the route.
STEP 3.2 If the exist in the route of the bus then
STEP 4 : All the busses in that particular route will be

checked
STEP 5: The bus that is closest to the queried stop is

checked first.
STEP 6: The bus whose next stop corresponds to the stop

name sent by the user through the SMS
STEP 6.1: if there does not exist any bus whose next stop
corresponds to the stop name sent by the user then the
system searches for a bus on the stop previous to that. It
continues searching until it finds a bus on a stop. The system
then adds up the time for the bus to reach each stop up to the
required stop.
STEP 7: System will send an SMS to the user about the

approximate timing of the bus to arrive at the queried bus
stop
STEP 8: SMS will be received
ALTERNATE COURSE OF ACTION NONE

PRE CONDITION SMS should be sent at a predefined format
POSTCONDITION NONE
ASSUMPTION NONE
35 of 125
008
36 of 125
008
USECASE NAME: Add a new bus Group

USECASE NAME: Add a new bus
ACTOR System administrator
DESCRIPTION: Adding a new bus Group.
DESCRIPTION: Adding a new bus.
STEP 1: System administrator will add a
STEP 1: system administrator will add a new
new Group of bus
bus.
STEP 2 : Add New Bus Group
STEP 2 : Add new bus
STEP 3: New bus Group is added
STEP 3: New bus is added

PRE
PRE CONDITION
CONDITION Bus
The should not exist
bus Group in not
should the database
exist
POSTCONDITION
POSTCONDITION Bus
The should existshould
bus Group in theexist
database
in the database
ASSUMPTION
ASSUMPTION NONE
NONE
37 of 125
008
USECASE NAME: Add a new route
DESCRIPTION: Adding a new route for new group of

busses
STEP 1: System administrator will add a new
route for new group of busses.
STEP 2 : System will give instruction how
to add a new route
STEP 3: New route for new group of bus is

added

PRE CONDITION 1. Route of that name should not exist
2. The bus Group to which the Route is
to be assigned should exist
POSTCONDITION Route must exist in the database

ASSUMPTION NONE
38 of 125
008
USECASE NAME: Add a new stop Location for Route Up
DESCRIPTION: Adding a new stop location for Route Up

new stop and the latitude and longitude of
that particular stop
STEP 2 : System will give instruction how to
add a new stop and its latitude and longitude
STEP 3: New stop for route up is added
PRE CONDITION Stop name and the latitude and longitude

should not exist
POSTCONDITION Stop name and latitude and longitude should

exist
ASSUMPTION NONE
USECASE NAME: Add a new stop Location for Route Down
DESCRIPTION: Adding a new stop location for Route Down

new stop and the latitude and longitude of
that particular stop
39 of 125
008
add a new stop and its latitude and longitude
STEP 3: New stop for route down is

added
PRE CONDITION Stop name and the latitude and longitude

should not exist
POSTCONDITION Stop name and latitude and longitude should

exist
ASSUMPTION NONE
USECASE NAME: Add a new stop in existing route for up
DESCRIPTION: Adding a new stop in the existing route for

up
STEP 1: System administrator will add a new

stop in the existing route
STEP 2 : System will give instruction how

to add a new stop
STEP 3: New stop in the route is added bus

is added
PRE CONDITION Stop name should not exist.

Next Stop must not exist against that
particular stop
40 of 125
008
POSTCONDITION Stop Name , Next Stop should exist
ASSUMPTION NONE
USECASE NAME: Add Driver
DESCRIPTION: Adding Driver

STEP 1: System administrator will add the
name of a new driver

add a new driver name
USECASE NAME: Add a new stop in existing route for Down
STEP 3: New Driver name is added
DESCRIPTION: Adding a new stop in the existing route for
PRE CONDITION Down
1. NIC number of that driver should not
exist.
2. License Number should exist in the
STEP 1: system administrator will add a new database.
stop in the existing route
POSTCONDITION Values Should be added in the database
ASSUMPTION STEP
NONE2 : System will give instruction how to
add a new stop
STEP 3: New stop in the route is added bus

is added
PRE CONDITION Stop name should not exist.

Next Stop must not exist against that
particular stop
POSTCONDITION Stop Name ,Next Stop should exist 41 of 125
ASSUMPTION NONE
008
USECASE NAME: Add a GSM /GPS Device
DESCRIPTION: Adding a new GSM GPS Modem

new GSM/GPS Modem

add a new Device
STEP 3: New device is added
PRE CONDITION The device of that particular GSM-id should

not exist
POSTCONDITION The device of that particular GSM-id should
exist in the database
ASSUMPTION NONE
42 of 125
008
USECASE NAME: Change Bus Device
DESCRIPTION: Chang the Device for a particular bus

STEP 1: System administrator will change
the Device ID for the particular Bus

change the Device
STEP 3: Device ID for the particular bus is
updated
PRE CONDITION The device ID should not be assigned

to any other bus
POSTCONDITION Values Should be updated in the database
ASSUMPTION NONE
43 of 125
008
USECASE NAME: Edit a bus Group
DESCRIPTION: Editing a bus Group that has been entered

wrong
STEP 1: System administrator will edit

Group of bus
STEP 2 : Update the changes
STEP 3: Bus Group is updated
PRE CONDITION The bus Group should not exist

POSTCONDITION The bus Group should exist in the database
ASSUMPTION NONE
44 of 125
008
USECASE NAME: Edit Bus
DESCRIPTION: Editing the Registration Number of the bus

STEP 1: system administrator will edit bus.
STEP 2 : Update the changed registration

number
STEP 3: Registration Number is Updated

PRE CONDITION Registration Number should not exist in the
database
POSTCONDITION Registration Number should be Updated in
the database
ASSUMPTION NONE
45 of 125
008
USECASE NAME: Edit route
DESCRIPTION: Edit route for group of busses

STEP 1: System administrator will edit a
route for new group of busses.
edit a route
STEP 3: Route is Updated

PRE CONDITION 1. Route of that name should not exist
2. The bus Group to which the Route is
to be assigned should exist
POSTCONDITION Route must be updated

ASSUMPTION NONE
46 of 125
008
USECASE NAME: Edit Stop Location for Up
DESCRIPTION: Editing stop location for Route Up
STEP 1: System administrator will and the

latitude and longitude of that particular stop

edit latitude and longitude against a particular
stop
STEP 3: Latitude and Longitude for a

particular stop are updated
PRE CONDITION latitude and longitude should exist against that

particular stop name
POSTCONDITION latitude and longitude should be updated
ASSUMPTION NONE
47 of 125
008
USECASE NAME: Edit stop Location for Down
ACTOR System Administrator
DESCRIPTION: Editing stop location for Down
STEP 1: System administrator will and the

latitude and longitude of that particular stop

edit latitude and longitude against a particular
stop
STEP 3: Latitude and Longitude for a

particular stop are updated
PRE CONDITION latitude and longitude should exist against that

particular stop name
POSTCONDITION latitude and longitude should be updated
ASSUMPTION NONE
48 of 125
008
USECASE NAME: Edit stop in existing route for Down
DESCRIPTION: Adding a new stop in the existing route.
STEP 1: system administrator will edit a

complete record in the existing route

edit complete record
STEP 3:Record Updated
STEP-4: System Administrator will edit only

certain values against a particular route name
STEP-5: System will give instruction how to

edit a certain record against a particular route
name
STEP-6: Record Updated
PRE CONDITION Stop name, next stop, time should exist.
POSTCONDITION Stop name , next stop and time should be

updated against the particular route
ASSUMPTION NONE
49 of 125
008
USECASE NAME: Edit stop in existing route for Up
DESCRIPTION: Adding a new stop in the existing route.
STEP 1: system administrator will edit a

complete record in the existing route

edit complete record
STEP 3:Record Updated
STEP-4: System Administrator will edit only

certain values against a particular route name
STEP-5: System will give instruction how to

edit a certain record against a particular route
name
STEP-6: Record Updated
PRE CONDITION Stop name, next stop, time should exist.
POSTCONDITION Stop name , next stop and time should be

updated against the particular route
ASSUMPTION NONE
50 of 125
008
USECASE NAME: Edit a GSM /GPS Device
DESCRIPTION: Editing GSM GPS Modem
STEP 1: System administrator will Edit a

GSM/GPS Modem

Edit the Device
STEP 3:Device ID Updated
PRE CONDITION The device of that particular GSM-id should

exist
POSTCONDITION The device of that particular GSM-id should

be updated in the database
ASSUMPTION NONE
51 of 125
008
USECASE NAME: Edit Driver Information
ACTOR System Administrator
DESCRIPTION: Editing Driver Information

STEP 1: System administrator will Edit the
name of a new driver , CNIC , License
Number
Edit the record
STEP 3: Record is Updated
PRE CONDITION 1. NIC number of that driver should

exist.
2. License Number should exist in the
database.
POSTCONDITION Record should be updated
ASSUMPTION NONE
52 of 125
008
USECASE NAME: Tracking with respect to Registration Number
DESCRIPTION: Tracking of the particular bus
STEP 1: System administrator will track the

bus on route by the Registration Number. STEP 2: System will give instruction how to
use the Registration Number for Tracking
STEP 3: Current Position of that particular

bus will be shown
PRE CONDITION Bus Instance of the Registration Number’s

should be created
POSTCONDITION NONE
ASSUMPTION NONE
53 of 125
008
USECASE NAME: Tracking with respect to Bus Name
DESCRIPTION: Tracking of the particular bus with respect to

Bus name
STEP 1: System administrator will track the

bus on route by the Bus Name. STEP 2: System will give instruction how to
use the Bus Name for Tracking
STEP 3: Current Position of the busses in

that route will be shown
PRE CONDITION Bus Instances of that Bus name should be

created
POSTCONDITION NONE
ASSUMPTION NONE
54 of 125
008
USECASE NAME: Terminate
DESCRIPTION: Terminating the instance of the bus when it

arrives at its destination.
STEP 1: System administrator will terminate

the instance of the bus that has arrived at the
destination
STEP 2: Terminate the bus instance and the

data of the GSM GPS Modem.
STEP 3: Bus Instance deleted
PRE CONDITION Bus should arrive at the destination
POSTCONDITION NONE
ASSUMPTION NONE
55 of 125
008
USECASE NAME: Bus Instance
DESCRIPTION: Creating a new bus instance.

STEP 1: System administrator will create a
new bus instance
STEP 2 : Create a new instance
STEP 3: New instance is created

PRE CONDITION The instance of one bus at the particular date
/time and the route will be created only once
POSTCONDITION NONE
ASSUMPTION NONE
56 of 125
008
USECASE NAME: Delete Bus
DESCRIPTION: Deleting the registration number of the bus

that has left the company.
STEP 1: System administrator will Delete

the registration number of the bus that has
left the company
STEP 2 : Delete the Registration Number of

the bus
STEP-3: Bus Deleted
PRE CONDITION Bus should have left the company
POSTCONDITION NONE
ASSUMPTION NONE
57 of 125
008
USECASE NAME: Delete Driver Information
DESCRIPTION: Deleting the information of the Driver that has

left the company.

the Driver information that has left the
company
STEP 2 : Delete the Driver information
STEP-3: Driver Information deleted

PRE CONDITION Driver should have left the company
POSTCONDITION NONE
ASSUMPTION NONE
58 of 125
008
USECASE NAME: Delete Device
DESCRIPTION: Deleting the Device that has been out of order

the Device that has been out of order
STEP 2 : Delete the Device
STEP-3: Device Number deleted
PRE CONDITION Device should be out of order
POSTCONDITION NONE
ASSUMPTION NONE
5.3 Design:
In design, the result of the analysis is expanded into a technical solution. New classes are added
to provide the technical infrastructure like the user interface, database handling to store objects in
a database, communication with other systems, interfacing to devices in the system, and others.
The design results in detailed specifications for the implementation activities.
Use case Name Add New Bus Group

Actor: System Administrator
Description: This use case describes the design adding a new bus Group
Reference: PS-1.0
59 of 125
008
Actor Action System Response Controls Constraints

Step-1: Will select the Bus name(Text box) Bus
Bus from the new name(Varchar)
menu of the menu strip. Step-2: On the The name of the
response, a new bus will be unique
form will open and
the following field
Step-3: The System will be appeared
Administrator will click Bus name
on the ADD button and
the values will be saved
in the database
Alternate Course Of Events: None
Preconditions: The name of that bus Group should not exist in the database
Post Conditions: The name of the bus exist in the database
Assumptions: None
Use case Name Add New Bus

Description: This use case describes the design adding a new bus
Reference: PS-1.0
Step-1: Will select the Registration Registration
New Bus from the menu Number (Text box) Number(Varchar)
strip. Step-2: On the GPSID (Combo GPSID(Varchar)
response, a new Box) Registration
form will open and Number and the
the following field GPSID against
will be appeared that Registration
Registration Number will be
Step-3: The System Number , GPS ID unique
Administrator will click
in the database
60 of 125
008
Preconditions: GSM Number assigned to that Registration Number should not be belong
to any other Registration Number
Post Conditions: New bus is added
Assumptions: None
Use case Name Add New Route

Description: This use case describes the design adding a new Route
Reference: PS-1.0
Step-1: Will select the Bus Name(Combo Bus
Route from the menu Box) Name(Varchar)
strip. Step-2: On the Route Name (Text Route Name
response, a new Box) (Varchar)
form will open and
the following fields
will be appeared
Bus Name
Step-3: The System Route Name
the values will be saved in
the database
Preconditions: The route name should not exist in the database
Post Conditions: The route name should exist in the database
Assumptions: None
Use case Name Add New Stop Location for route Up

Description: This use case describes the design adding a new Stop Location for Route Up
Reference: PS-1.0
61 of 125
008

Step-1: Will select the Stop Name (Text Stop Name (text)
Stop and Up from the box) Latitude(Varchar)
New menu strip. Step-2: On the Latitude(Text Box) Longitude(Varchar)
response, a new Longitude(Text Stop Name,
form will open and Box) Latitude, Longitude
the following field should be unique.
swill be appeared
Stop Name
,Latitude,
Step-3: The System Longitude
in the database
Preconditions: Stop Name, Latitude, Longitude should not exist in the database
Post Conditions: Stop Name, Latitude, Longitude should exist in the database
Assumptions: Latitude and Longitude belongs to the stop
Use case Name Add New Stop Location for Route Down
Description: This use case describes the design adding a new Stop Location for Route Down
Reference: PS-1.0
Step-1: Will select the Stop Name (Text Stop Name
Stop and Down from the box) (text)
New menu strip. Step-2: On the Latitude(Text Box) Latitude(Varcha
response, a new Longitude(Text Box) r)
form will open and Longitude(Varc
the following field har)
swill be appeared Stop Name,
Stop Name Latitude,
,Latitude, Longitude
Step-3: The System Longitude should be
Administrator will click unique.
62 of 125
008

in the database
Preconditions: Stop Name, Latitude, Longitude should not exist in the database
Post Conditions: Stop Name, Latitude, Longitude should exist in the database
Assumptions: None
Use case Name Add New Stop in existing Route for Up

Description: This use case describes the design adding a new Stop in existing Route for Up
Reference: PS-1.0
Step-1: Will select the Route Name (Text Route Name
Stop In Route and Up Box) (Varchar)
from the New Menu Step-2: On the Stop Name(Combo Stop
Strip. response, a new Box) Name(Varchar)
form will open and Next Stop (Combo Next Stop
the following fields Box) (Varchar)
will be appeared Stop Number(Text Stop
Route Name Box) Number(int)
Step-3: The System Stop Name Time (Text Box) Time(int)
Administrator will click Next Stop Name
on the ADD button and Stop Number
the values will be saved Time The stop name in
in the database that particular
route name
should be unique
The next stop in
that particular
route should be
unique
63 of 125
008
Preconditions: The Stop Name, Next Stop in that particular route name should not exist in
the database
Post Conditions: The Stop Name in that particular route name should exist in the database
Assumptions: None
Use case Name Add New Stop in existing Route for Down
Description: This use case describes the design adding a new Stop in existing Route for Down
Reference: PS-1.0
Step-1: Will select the Route Name (Text Route Name
Stop In Route and Box) (Varchar)
Down from the New Step-2: On the Stop Name(Combo Stop
Menu Strip. response, a new Box) Name(Varchar)
form will open and Next Stop (Combo Next Stop
the following fields Box) (Varchar)
will be appeared Stop Number(Text Stop Number(int)
Route Name Box) Time(int)
Step-3: The System Stop Name Time (Text Box)
Administrator will click Next Stop Name
on the ADD button and Stop Number The stop name in
the values will be saved Time that particular route
in the database name should be
unique
The next stop in
that particular route
should be unique
Preconditions: The Stop Name, Next Stop in that particular route name should not exist in
the database
Post Conditions: The Stop Name in that particular route name should exist in the database
Assumptions: None
64 of 125
008
Use case Name Add New GSM/GPS Modem

Description: This use case describes the design adding a new GSM/GPS Modem
Reference: PS-1.0
Step-1: Will select the Device ID (TextBox) GSM
DEVICE from New Number(Varchar)
menu of the menu strip. Step-2: On the
response, the
following field will
be appeared
Device ID
Step-3: The System
in the database
Preconditions: The GSM Number of that device should not exist in the database
Post Conditions: The GSM Number of that device should exist in the database
Assumptions: None
Use case Name Add New Driver

Description: This use case describes the design adding a new Driver Name
Reference: PS-1.0
Step-1: Will select the NIC(TextBox) NIC(Varchar)
DRIVER from New Driver Name(Text Driver
menu of the menu strip. Step-2: On the Box) Name(Varchar)
response, the License License
following fields will Number(Text Box) Number(Varchar)
be appeared
NIC
Step-3: The System Driver name
65 of 125
008
Administrator will click License Number

in the database
Preconditions: NIC Number and the License Number should not exist in the database
Post Conditions: NIC Number and the License Number should exist in the database
Assumptions: None
Use case Name Change Device of a Bus

Description: This use case describes the design of changing the Device for the particular bus
Reference: PS-1.0
Step-1: Will select the Registration Registration
Change New menu Number (Combo Number (Varchar)
strip. Step-2: On the box) Device ID(Varchar)
response, a new Current Device
form will open and ID(Text Box)
the following field New Device ID(Text
swill be appeared Box)
Registration
Number, Current
Step-3: The System Device ID , New
Administrator will click Device ID
on the Change button
and the values will be
updated in the database
Preconditions: Device ID should not be assigned to any other bus
Post Conditions: The Device ID should be updated
Assumptions: None
66 of 125
008
Use case Name Edit Bus Group

Description: This use case describes the design of Editing a bus Group
Reference: PS-1.0
Step-1: Will select the Current Bus Bus name(Varchar)
Bus Name from the Edit name(Combo box) The name of the
menu of the menu strip. Step-2: On the New Bus Name(Text bus will be unique
response, a new Box)
form will open and
the following field
Step-3: The System will be appeared
Administrator will click Current Bus Name
on the Change button New Bus Name
Preconditions: Bus Name should exist in the database
Post Conditions: Bus Name should be updated
Assumptions: None
67 of 125
008
Use case Name Edit Bus

Description: This use case describes the design of editing a Registration Number
Reference: PS-1.0
Step-1: Will select the Current Registration
Registration Number Registration Number(Varchar)
from Edit menu strip. Step-2: On the Number (Combo Registration
response, a new box) Number should be
form will open and New Registration unique
the following field Number (Text Box)
will be appeared
Current
Step-3: The System Registration
Administrator will click Number , New
on the Change button Registration
and the values will be Number
Updated in the database
Preconditions: Registration Number should not exist in the database
Post Conditions: Registration Number is updated
Assumptions: None
68 of 125
008
Use case Name Edit Route

Description: This use case describes the design Editing a Route
Reference: PS-1.0
Step-1: Will select the Current Route Route Name
Route from the Edit Name (Combo Box) (Varchar)
menu strip. Step-2: On the New Route Name Route name must
response, a new (Text Box) be same as the
form will open and name of the group
the following fields of buss.
will be appeared
Current Route
Step-3: The System Name
Administrator will click New Route Name
update in the database
Preconditions: The route name should exist in the database
Post Conditions: The route name should be updated
Assumptions: None
69 of 125
008
Use case Name Edit Stop Location For Up

Description: This use case describes the design editing a stop’s Latitude and Longitude
Reference: PS-1.0
Step-1: Will select the Stop Name (Combo Stop Name (text)
Stop and then select Up Box) Latitude(Varchar)
from the Edit menu Step-2: On the Current Longitude(Varchar)
strip. response, a new Latitude(Combo Stop Name,
the following field Current should be unique.
swill be appeared Longitude(Combo
Stop Name Box)
,Current Latitude, New Latitude(Text
Current Longitude Box)
Step-3: The System , New Latitude , New Longitude(Text
Administrator will click New Longitude Box)
saved in the database
Preconditions: Stop Name, Latitude, Longitude should exist in the database
Post Conditions: Latitude, Longitude should be updated in the database
Assumptions: None
Use case Name Edit Stop Location For Route Down

Description: This use case describes the design editing a stop’s Latitude and Longitude
Reference: PS-1.0
Step-1: Will select the Stop Name (Combo Stop Name (text)
Stop and then select Box) Latitude(Varchar)
Down from the Edit Step-2: On the Current Longitude(Varchar)
menu strip. response, a new Latitude(Combo Stop Name,
the following field Current should be unique.
swill be appeared Longitude(Combo
70 of 125
008
Stop Name Box)

,Current Latitude, New Latitude(Text
Current Longitude Box)
Step-3: The System , New Latitude , New Longitude(Text
Administrator will click New Longitude Box)
saved in the database
Preconditions: Stop Name, Latitude, Longitude should exist in the database
Post Conditions: Latitude, Longitude should be updated in the database
Assumptions: None
Use case Name Edit Stop in existing Route for Down

Description: This use case describes the design Editing a Stop in existing Route for Down
Reference: PS-1.0
Step-1: Will select the Current Route Route Name
Stop In Route and Name(Combo Box) (Varchar)
Down from the Edit Step-2: On the New Route Name Stop
Menu Strip. response, a new (Combo Box) Name(Varchar)
form will open and Current Stop Next Stop (Varchar)
the following fields Name(Combo Box) Time(int)
will be appeared all New Stop
these fields will be Name(Combo Box)
disabled. Current Next Stop The stop name in
Current Route (Text Box) that particular route
Name New Next Stop name should be
New Route Name (Combo Box) unique
Current Stop Name Current Time(Text The next stop in that
New Stop Name Box) particular route
Current Next Stop New Time (Text should be unique
New Next Stop Box)
Current Time
New Time
The following
71 of 125
008
buttons will be on
the interface
Edit Complete
Record
Edit Stop Name
Step-4: The System Edit Next Stop
Administrator will click Edit Time
on the Change button Step-3: If the Edit
and the values will be Complete Record
updated in the database Button is clicked
then all the fields
will be enabled.
Step-6: The System Step-5: If Edit Stop

Administrator will click Name Button is
on the Change button clicked then the
and the values will be following fields will
updated in the database be enabled
Current Route
Name
Current Stop Name
New Stop Name
Step-8: The System

and the values will be Step-7: If Edit Next
updated in the database Stop Button is
clicked then the
following fields will
be enabled
Current Route
Name
Current Stop Name
Current Next Stop
Step-10: The System New Next Stop
72 of 125
008

Step-9: If Edit
Time Button is
clicked then the
following fields will
be enabled
Current Route
Name
Current Stop Name
Current Next Stop
Current Time
New Time
Preconditions: The Stop Name, Next Stop, time in that particular route name should exist in the
database
Post Conditions: The Stop Name, Next Stop, Time in that particular route name should be
Assumptions: None
73 of 125
008
Use case Name Edit GSM/GPS Modem

Description: This use case describes the design of editing a GSM/GPS Modem’s ID
Reference: PS-1.0
Step-1: Will select the GSM Number GSM
GPS DEVICE from (TextBox) Number(Varchar)
Edit menu of the Menu Step-2: On the The Device
Strip. response, the Number should be
following field will unique
be appeared
Current Device
Number
Step-3: The System New Device Number
Preconditions: The Device Number of that device should exist in the database
Post Conditions: The Device Number of that device should be updated in the database
Assumptions: None
74 of 125
008
Use case Name Edit Driver Information

Description: This use case describes the design of editing the Driver information
Reference: PS-1.0
Step-1: Will select the Current CNIC(text NIC(Varchar)
DRIVER from Edit Box) Driver
menu of the menu strip. Step-2: On the New CNIC(Text Name(Varchar)
response, the Box) License
following fields will Current Driver Number(Varchar)
be appeared Name(Combo Box)
Current CNIC New Driver
New CNIC Name(Text Box)
Current Driver Current License
name Number(Text Box)
New Driver Name New License
Step-3: The System Current License Number(Text Box)
Administrator will click Number
on the Change button New License
and the values will be Number
Preconditions: CNIC and the License Number should exist in the database
Post Conditions: CNIC and the License Number should be updated in the database
Assumptions: None
75 of 125
008
Use case Name: Tracking with respect to Registration Number

Description: This use case describes the design of Tracking the bus with respect to its
Registration Number
Reference: PS-1.0
Step-1: Will select Registration Registration
Current Location and Number(Combo Number(Varchar)
then Registration Step-2: On the Box)
Number from Track response, a form
Menu Strip. containing the
be appeared
Registration
Number
Step-3: The System
on the Track button and
the current stop of that
bus will be shown in the
text box
Preconditions: The bus instance should have been created
Post Conditions: Current Stop of the bus should be shown
Assumptions: None
76 of 125
008
Use case Name: Tracking with respect to Bus Name

Description: This use case describes the design of Tracking the bus with respect to its Bus
Name
Reference: PS-1.0
Step-1: Will select Bus Name(Combo Bus
Current Location and Box) Name(Varchar)
Bus Name then from Step-2: On the
Track Menu Strip. response, a form
containing the
be appeared
Bus Name
Step-3: The System
on the Track button and
the current stops of the
busses will be shown in
the Grid
Assumptions: None
77 of 125
008

Assumptions: None
Alternate Course Of System Response Controls Constraints
Events: None
Preconditions: The bus Registration Registration
instance should have been Number(Combo Number(Varchar
created Step-2: On the Box) )
response, a form
containing the
be appeared
Registration
Number
Post Conditions: The bus instance should be terminated
Assumptions: None
Use case Name: Bus Instance

Description: This use case describes the design of Creating a new Bus Instance
Reference: PS-1.0
Step-1: Registration Registration
Number(Combo Number(Varchar)
Step-2: On the Box) Bus
response, a form Bus Name(Combo Name(Varchar)
containing the box) Device ID
Step-3: The System following fields Device ID(Read only (varchar)
Administrator will click will be appeared Text Box) Date
on the Transmit button Bus Name Date Time(Read Time(DateTime)
and the data will be ,Registration Only Text Box) Driver
started to upload on the Number, Device Driver Name(Combo Name(Text)
78 of 125
008
internet ID , Date Time, Box) Route(bit)

Driver Name, Route(Radio button Starting
Route ,Starting of up /Down) Stop(Varchar)
Stop, Remarks Starting Stop(Text Remarks(Varchar)
Box)
Remarks(Rich Text
Box)
Preconditions: None
Post Conditions: None
Assumptions: None
Use case Name: Delete Bus

Description: This use case describes the design of Deleting the bus that has left the company
Reference: PS-1.0
Step-1: Will select Bus Registration Registration
from the Delete menu of Number(Combo Number(Varchar)
the Menu Strip. Step-2: On the Box)
response, a form
containing the
be appeared
Step-3: The System Registration
Administrator will click Number
on the Delete button and
that particular bus will be
deleted
Preconditions: The bus should have left the company
Post Conditions: The bus’s registration number should be deleted from the record
79 of 125
008
Assumptions: None
Use case Name: Delete Driver Information

Description: This use case describes the design of Deleting the Driver’s information that has
left the company
Reference: PS-1.0
Step-1: Will select Driver Driver Name(Combo Driver
from the Delete menu of Box) Name(Varchar)
the Menu Strip. Step-2: On the
response, a form
containing the
be appeared
Step-3: The System Driver Name
Administrator will click on
the Delete button and
driver information will be
deleted
Preconditions: The Driver should have left the company
Post Conditions: The Driver’s information should be deleted from the record
Assumptions: None
Use case Name: Delete Device

Description: This use case describes the design of Deleting the Device that has been out of
order
Reference: PS-1.0
Step-1: Will select GPS Device ID(Combo Device
Device from the Delete Box) ID(Varchar)
menu of the Menu Strip. Step-2: On the
response, a form
80 of 125
008
containing the
be appeared
Step-3: The System Device ID
Administrator will click on
the Delete button and
Device will be deleted
Preconditions: The Device should be out of order
Post Conditions: The Device Information should be deleted from the record
Assumptions: None
81 of 125
008
CHAPTER
Implementation
6
82 of 125
008
6. Implementation
In this chapter we have discussed some implementation details like application’s major
constituent development and interface design of the application.
6.1 Application Interfaces:
1. Administrator can add new bus group name by using following interface in Fig 6.1.
Fig. 6.11 Add a new Bus Group
2. Administrator can add new bus by using following interface, the two fields can get
registration number of bus and GPS device id against that registration number Fig 6.2. Each
bus contains as GPS-GPRS device.
83 of 125
008
Fig. 6.12 Add a new Bus
3. The following interface is used to add new route name against any particular bus
name.Administrator can select any bus using drop down menu and define new route name
against that stop Fig 6.3.
Fig. 6.13 Add a new Route
84 of 125
008
4. Adiministrator can define new stop by entering respective logitude and latitude of the
respective stop in up direction,using the following interface Fig 6.4.
Fig. 6.14 Add new Stops and their locations for Route Up
5. Adiministrator can define new stop by entering respective logitude and latitude of the
respective stop in down direction,using the following interface he can define it easily by
putting the respective values, interface view is mentioned in Fig 6.5.
85 of 125
008
Fig. 6.15 Add new Stops and their locations for Route Down
6. When a new device is purchased by the company , administrator can register that device
using following interface Fig 6.6.
Fig. 6.16 Add a new Device
86 of 125
008
7. When a new driver is recruited administrator can register him by using following interface.
Driver’s name, CNIC, license no is updated in the database by using following interface Fig
6.7.
Fig. 6.17 Add a new Driver and its Information
8. Adiministrator can define new stop in route by entering data of the respective stop for up
direction by using the following interface Fig 6.8.
87 of 125
008
Fig. 6.18 Add Stops for the route up
9. Adiministrator can define new stop in route by entering respective data of the respective stop
for down direction by using the following interface Fig 6.9.
88 of 125
008
Fig. 6.19 Add Stops for the route down
10. Any device related data that is registered in the database can be edited by following
interface,adminitrator can enter new device number with respect to old one Fig 6.10.
Fig. 6.20 Edit the Device Number
89 of 125
008
11. Similarly any bus related data that is regitered in the database can be edited by following
interface,adminitrator can enter new bus name with respect to current bus name Fig 6.11.
Fig. 6.21 Edit the Bus Name
12. Route name can also be edited by using following interface,by replacing the current with new
one, interface view is mentioned in Fig 6.12.
Fig. 6.22 Edit the Route Name
90 of 125
008
13. By using following interface administrator can edit data related any stop indivisiually or the
complete stop information is also edited by using the same interface,having route for up
direction, interface view is mentioned in Fig 6.13.
Fig. 6.23 Edit the Stop in Route Up
91 of 125
008
14. Similarly following interface is used to edit data related to any stop indivisiually as well as
complete stop information is also edited by using the same interface,having route for down
direction, interface view is mentioned in Fig 6.14.
Fig. 6.24 Edit the Stop in Route Down
15. Any bus registertion data that is regitered in the database can be edited by following
interface,adminitrator can enter new registeration number with respect to old one, interface
view is mentioned in Fig 6.15.
92 of 125
008
Fig. 6.25 Edit Registration Number
16. If the respective logitude and latitude of the stop up is changed then it can be edited by using
following interface.The old longitude and latitude can be replaced by new ones (Fig 6.16).
Fig. 6.26 Edit Stop Location for Route Down
93 of 125
008
17. If the respective logitude and latitude of the stop down is changed then it can be edited by
using following interface.The old longitude and latitude can be replaced by new ones (Fig
6.17).
Fig. 6.27 Edit Stop Location for Route Up
18. If any bus is retired form the fleet then administerator can also delete the data e of respective
bus by using following interface (Fig 6.18).
94 of 125
008
Fig. 6.28 Delete the Bus that has left the company
19. Similarly if any driver is retired or resigned form the company then administerator can also
delete the data of respective driver by using following interface (Fig 6.19).
Fig. 6.29 Delete the Driver Information
20. GPS device can also deleted from database by using following interface.Simply select the
respective GPS device-ID from the drop down menu and press the delete button (Fig 6.20).
95 of 125
008
Fig. 6.30 Delete the Device that has been defected
21. When the bus of any route reaches to its destination, administrator can terminate that bus
with respect to its registration number (Fig 6.21).
Fig. 6.31 Terminate the bus instance of the bus that has reached its destination
22. Adminitrator can also track any bus of any route,he can insatantaneously get the current
location of the respected bus by entering the bus name for up or down (Fig 6.22).
96 of 125
008
Fig. 6.32 Track the current location of the buss with respect to the bus name
23. following interface is the major interface of the application,when any bus of any route starts
its new route cycle means that it started its journy towards the last stop of the route,
administraor activate new bus instance by putting the respective data about bus and driver
respectivly.The instance can be viewed at any time (Fig 6.23 & 6.24).
97 of 125
008
Fig. 6.33 Create a new Instance of the bus
Fig. 6.34 Bus instance detail
98 of 125
008
6.2 User Service:
User will send a SMS for the enquiry of the particular bus. OZEKI Message Server will receive
the SMS and will place it in the SMSIN folder as .MSG file. A window service will receive that
SMS file from the folder and perform the following tasks
1. It will check the name of the bus user inquired is valid or not.
2. If it is not valid then the system will send a SMS to the user that the following bus name does
not exist.
3. If the bus name is valid then it will verify the Stop name that user has inquired about whether
the stop name belong to the bus name which user has inquired
4. If the stop name does not exist against that bus name which user has inquired then a SMS
will be sent to the user about the validity if the stop name
5. If the stop name is verified and it exist in the route of that bus then service will verify the
route. Route can be either 0 or1.
6. If route is not 0 or 1 then the SMS will be sent to the user that the route is not valid
7. If the route is valid then the service will check whether the route is 1 or 0.
8. If it is 1 then the service will check the stop number of the stop which user has inquired.
9. Then all the busses in that route will be checked whose stop number is less then the inquired
stop and that bus will be selected which is nearest to the inquired stop name , the stop
99 of 125
008
number of that bus will be calculated , the difference between the inquired stop name and the
selected stop name will be calculated .
10. Then the approximate timing of the bus to arrive at the inquired stop will be sent to the user
via SMS.
11. If it is 0 then the service will check the stop number of the stop which user has inquired.
12. Then all the busses in that route will be checked whose stop number is less then the inquired
stop and that bus will be selected which is nearest to the inquired stop name , the stop
number of that bus will be calculated , the difference between the inquired stop name and the
selected stop name will be calculated .
13. Then the approximate timing of the bus to arrive at the inquired stop will be sent to the user
via SMS.
The service will place a .MSG file in the SMS OUT folder and the OZEKI Message Server will
receive it from the folder and send it to the users.
6.3 Device Service:
The FM4100 GPS/GSM Modem will send the data on the real IP. The device will send NMEA
sentence. That NMEA sentence will be received by a service of the application. The NMEA
sentence is parsed and the device ID of the device and longitude, latitude of the current location
of the buss will be taken. Those longitude and latitude will be compared with the latitude and
longitude of the stop. If those longitude and latitude are similar to the latitude and longitude of a
100 of 125
008
stop in that route then the current location of that particular bus will be updated. If those
longitude and latitude does not correspond to any stop in the route of that bus then they will be
discarded and the current location of the bus will not be updated. The service will do the
following as the data appears on the IP.
1. It will parse the NMEA sentence and the relevant fields Device ID, latitude and longitude
will be separated from the sentence.
2. The latitude and longitude of that device on the bus will be compared with the latitude and
longitude of the stops in the route to which the bus belong.
3. If the latitude and longitude match the latitude and longitude of any stop in that route then the
current location of that bus will be updated, if they does not match then they will be
discarded
6.3.1TeltonikaFM4100
FM4100 is a terminal with GPS and GSM connectivity, which is able to get device coordinates
and transfer them via GSM network. This device is perfectly suitable for applications where
location acquirement of remote objects is needed. So you can track your remote objects (trucks,
cars, ships etc) quickly and easily.
It has option of rechargeable battery inside and special controller for power management. Also
there is an option of using external backup battery. Thus it can operate for up to 48 hours in
Normal (Sending via GPRS) mode with external backup battery. FM4100 can perform tasks on
remote objects, such as monitoring temperature, engine status, fuel consumption, controlling
101 of 125
008
truck’s door etc. In case of losing connection FM4100 (Fig 6.25) can store up to 8000 records
(optionally 64000 records), and once the connection is established the device will send stored
data via GPRS. The aluminum case of the device is very robust and perfectly suitable for
installation into harsh environment [5].
Fig. 6.35 TeltonikaFM4100 [5]
102 of 125
008
CHAPTER
Database Implementation
7
103 of 125
008
7. Database Implementation
In this chapter we have elaborated database implementation detail by using entity relationship
diagram.
7.1.1Entity Relationship diagrams
Complete Entity relationship diagram of transport information system is mentioned is Fig 7.1.
The major table that is backbone of the data base is “bus instance” table, every time when a bus
of any route starts its new trip its instance is created in the database by using that table. It simply
gathers all bus related data from other tables and integrate it.
104 of 125
008
Fig. 7.36 System Entity Relationship Diagram
105 of 125
008
CHAPTER
Testing
8
106 of 125
008
8. Testing
In this chapter we have discussed all test cases and test criteria that we used to test application at
each stage.
8.1 Testing Areas
1. Phase1: Individual testing
2. Phase2:Partial testing
3. Phase3:Integeration testing
8.2 Testing phases
8.2.1Phase 1
8.2.1.1 Database testing
In first phase of testing we evaluated each module individually. First of all database the backbone
of our project is tested which includes.
1. Each stored procedure of insert, delete, and update is tested in query analyzer.
2. Verification of the status of changes done through these statements in tables manually.
107 of 125
008
8.2.1.2 Window service testing
User service is continuously watching a particular path ( folder”SMSIN”) when it is started and
when new SMS is arrived it prompts the application for further processing. Manually service
testing is performed by using following steps
1. Placing a file having “.msg” extension in SMSIN folder.
1.1. Writing wrong route no in the SMS and check the response of service.
1.2. Checking the validity of format of the received SMS.
2. Placing a file of other extension in SMSIN folder, service will take no action.
8.2.1.3 GSM interface testing
Now comes the interfacing with GSM modem part in which we tested the functionality of
OZEKI message server and customize it for our specific use in Transport Information System.
SMS is sent from a mobile and the OZEIKI message server receives the SMS and placed the
.Msg file in the SMSIN folder. User service receives that SMS and perform all the functionality,
created a .Msg file and placed the response to that SMS in that file and placed that file in
SMSOUT folder. The Message server receives that file and sent it to the user who sent the
message.
8.2.2Phase 2
108 of 125
008
After testing each module individually, we integrated the database with GUI and run particular
queries using graphical user interface of the application.
8.2.2.1 GUI database integration
1. If the data is inserted using GUI then a message will prompt “Record inserted”.
2. If the data is updated using GUI then a message will prompt “Record updated”.
3. If the data is deleted using GUI then a message will prompt “You have deleted the following
record”.
8.2.2.2 Window service and database integration
1. If the respective bus name is incorrect the application will respond in form of simple text
message having text as follows “Dear customer, bus name <busname> is invalid”.
2. If the stop name is incorrect or the stop name does not exist in that particular route then the
application will respond the following “Dear customer, the stop name <stopname> is
invalid”.
3. If all the information is correct then application respond approximate arrival time of the
desired bus on user’s particular stop ;format is as follows “Dear customer, the bus
<busname> will arrive at <stopname> in <time> minutes”.
8.2.3Phase 3
109 of 125
008
In third test phase we integrated all four modules and perform SMS send receive service and
time calculation using GPS coordinates in back ground.
8.2.3.1 Integration testing
The message is received in the SMSIN folder and then service retrieves that file and for each
route it performs the following tasks.
invalid”.
110 of 125
008
CHAPTER
Results
9
111 of 125
008
9. Results
In testing phase the service is tested manually, that entire test results are mentioned in this
chapter; in testing processes some beneficial results are achieved.
1. When the user enter wrong stop name in the respective SMS our window service responded
immediately that the stop name is incorrect as mentioned below is in Fig 9.1 & 9.2
respectively.
Fig. 9.37 Wrong stop name
112 of 125
008
Fig. 9.38 Reply of wrong stop name
2. Similarly if the user enter wrong route name in the SMS the service respond the user that
route name is incorrect as mentioned below is in Fig 9.3 & 9.4 respectively.
113 of 125
008
Fig. 9.39 Wrong route
Fig. 9.40 Reply of Wrong route
114 of 125
008
3. If incorrect bus name is received in the SMS the service inform the user that respective bus
name is incorrect as mentioned below is in Fig 9.5 & 9.6 respectively.
Fig. 9.41 Wrong bus name
115 of 125
008
Fig. 9.42 Reply wrong bus name
4. Service responds with correct time if and only if the respected format of the SMS is correct
as mentioned below is in Fig 9.7 & 9.8 respectively. The service extracts the respective data
from the received SMS, perform calculations with respect to that received data and respond
the user with correct time of bus arrival at that stop.
116 of 125
008
Fig. 9.43 Correct format
Fig. 9.44 Correct Reply
117 of 125
008
CHAPTER
Discussion
10
118 of 125
008
10.Discussion
In the current chapter we have discussed the progression of the project including the methods
used and the results of experimentation, or the design.
invalid”.
119 of 125
008
CHAPTER
Conclusion
11
120 of 125
008
11.Conclusion
This chapter of report contains a concise statement of the conclusions is drawn from the work
attempted. We also focused to convince the reader that our actual will work without a flaw.
Transport information system is an automatic application informs commuters about the arrival
time of the bus they want to travel using SMS facility of their mobile phones; busses are tracked
using GPS-GSM modem embedded device that updates current longitude and latitude of bus in
database using GPRS technology. Application serves the remote users by manipulating that data
for arrival time calculation of the desired bus.
121 of 125
008
CHAPTER
Future Work
12
122 of 125
008
12.Future Work
In the current chapter we pointed out some major future enhancements & implementations that
can made transport information system more effective and beneficial.
1. The application can be made web based and distributed.
2. Designing of special purpose hardware for interfacing GSM modem to the software
application serving multiple customers at a single time instance.
3. Implementation of intelligent queuing model at server end to reduce the response time of the
application.
4. Implementation of map based tracking of buses at administrator end.
5. Replacing the GPS+GPRS embedded device with single GPS device and GSM modem of
cell phone to make TIS cost effective.
123 of 125
008
CHAPTER
References
13
124 of 125
008
13.References
13.1 Web References
[1] Overview of GSM: The Global System for Mobile Communications, by John Scourias,
University Of Waterloo.
https://styx.uwaterloo.ca/publications/pdfs/TR-96-01.pdf
[2] http://www.aero.org/education/primers/gps/howgpsworks.html
[3] How GPS Receiver Works, by Marshall Brain & Tom Harris.
http://adventure.howstuffworks.com/gps4.htm
[4] NMEA Data, by Dale DePriest.
http://gpsinformation.org/dale/nmea.htm
[5] http://www.teltonika.lt/en/pages/view/?id=762
125 of 125

Tis

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Tis

Uploaded by

Copyright:

Available Formats

Transport Information System 2

3.2 AIMS AND OBJECTIVES:.............................................................................................................11

3.3 PROJECT SCOPE........................................................................................................................11

3.4 SYSTEM DESCRIPTION:..............................................................................................................12

3.5 ACTUAL DESIGN:.....................................................................................................................12

3.6 UNIVERSITY REQUIREMENT:.......................................................................................................13

3.7 SYSTEM MODULE:....................................................................................................................14

3.8 SYSTEM COMPONENTS:.............................................................................................................16

3.9 POTENTIAL CLIENTS:................................................................................................................16

4.1.1 History of GSM.............................................................................................................18

5.1 ACTOR USE CASE DIAGRAM:....................................................................................................30

6.2 USER SERVICE:........................................................................................................................99

6.3 DEVICE SERVICE:...................................................................................................................100

8.2 TESTING PHASES.....................................................................................................................107

8.2.1 Phase 1.......................................................................................................................107

FIG. 3.1 SYSTEM VIEW...........................................................................................................13

FIG. 6.27 EDIT STOP LOCATION FOR ROUTE UP...........................................................94

the current location of the vehicle.

locations and the data of both the busses should be maintained.

extra personal computer.

performance specification and block diagram of transport information system.

3.1 System Overview:

(Public Transport) on their cell phones screens.

3.2 Aims and Objectives:

To make information system to facilitate public transport passenger especially in Karachi by

3.3 Project Scope

alternate of commuting in the city in their personal vehicles.

easily accessible on the screens of their cell phones.

3.4 System Description:

approximate timing of the bus which he/she has queried.

3.5 Actual Design:

location is uploaded on a real IP by using GPRS technology. Database is continuously updated

by current location of the particular bus.

on GMSM modem installed on server. Complete system overview of transport information

system is described in Fig 3.1.

1. Commuter send an inquiry SMS to server.

2. SMS received at server through GSM network.

3. Server is continuously updated by the current location of each bus on route.

Fig. 3.1 System view

3.6 University Requirement:

to new scope we have to focus on system design defined in Fig 3.2.

Fig. 3.2 Updated System View

3.7 System Module:

The system comprises of three modules

windows service to the database server.

and parse the message and apply the following checks:

1. If the bus name exists or not.

does not belongs to the route.

bus that is closest to the queried stop is checked first.

the SMS is sent back to the user.

server sends the file as a SMS to the user.

3.8 System Components:

The system consists of the following components

3.9 Potential Clients:

1. Busses like Metro Bus Service and UTS

2. National Logistic Cell

constituent design & execution of transport information system.

4.1 GSM Network

within a selected system boundary.

1. Good subjective speech quality

2. Low terminal and service cost

3. Support for international roaming

4. Ability to support handheld terminals

5. Support for range of new services and facilities