Traffic Live: A Study of In-Car Satellite Navigation and GPS

Project III Henry Williams
Traffic:Live!
Individual Project
Henry Williams
h.e.l.williams@ex.ac.uk
Page 1 of 122
Table of Contents Page No.
1. Introduction ............................................................................................................................. 5
1.1. Concept ............................................................................................................................ 5
1.2. Project Statement ........................................................................................................ 5
2. Existing Solutions................................................................................................................... 7
2.1. Platforms ......................................................................................................................... 7
2.2. Packages.......................................................................................................................... 7
3. Routing Algorithms.............................................................................................................. 11
3.1. Standard Algorithms ................................................................................................. 11
3.2. Intelligent Algorithms .............................................................................................. 11
3.3. Dealing With Changes .............................................................................................. 12
3.4. Conclusion..................................................................................................................... 12
4. Communication Technologies.......................................................................................... 14
4.1. Medium........................................................................................................................... 14
4.2. Language ....................................................................................................................... 14
5. User Interface........................................................................................................................ 16
6. New Technologies ................................................................................................................ 17
6.1. Geographical Mark-up Language (GML) for mapping .................................. 17
6.2. Global Positioning System (GPS) for location ................................................. 18
6.3. Conclusion..................................................................................................................... 19
7. System Requirements......................................................................................................... 20
8. System Architecture............................................................................................................ 21
9. Formal Backend Modelling................................................................................................ 22
9.1. Use Cases ...................................................................................................................... 22
9.2. Activity Diagrams ....................................................................................................... 22
9.3. State Charts.................................................................................................................. 23
9.4. Class and Relationships ........................................................................................... 23
10. Front End Design .................................................................................................................. 25
10.1. Design............................................................................................................................. 25
10.2. Programming ............................................................................................................... 26
10.3. Input and Output........................................................................................................ 26
11. Algorithm Design.................................................................................................................. 28
11.1. A* Routing Algorithm ............................................................................................... 28
11.2. Distance Calculation Formula ................................................................................ 28
12. Network Design .................................................................................................................... 29
13. Messaging and the Global Positioning System (GPS) ............................................ 30
13.1. Message Format.......................................................................................................... 30
13.2. Message Sending........................................................................................................ 30
13.3. Message Receiving..................................................................................................... 31
13.4. Integration into network......................................................................................... 31
14. RAID .......................................................................................................................................... 32
15. Implementation, Simulation, Demo and Testing ..................................................... 34
15.1. Implementation Considerations ........................................................................... 34
15.2. Simulation for the Demonstration and Viva..................................................... 34
15.3. System White Box Testing ...................................................................................... 35
15.4. System Black Box Testing ....................................................................................... 37
15.5. Routing White and Black Box Testing ................................................................ 37
Page 2 of 122
15.6. Usability Testing ......................................................................................................... 38

15.7. Results and Recommendations............................................................................. 41
16. Critique..................................................................................................................................... 44
17. Bibliography ........................................................................................................................... 46
18. References .............................................................................................................................. 47
Appendix A – Software Reviews............................................................................................. 49
A.1. Microsoft Autoroute 2002 ............................................................................................ 49
A.2. ViaMichelin......................................................................................................................... 50
A.3. The AA.................................................................................................................................. 51
A.4. The RAC............................................................................................................................... 52
A.5. Tom Tom for the PocketPC .......................................................................................... 53
Appendix B – Routing Algorithms .......................................................................................... 54
B.1. Link State algorithms (LS) ........................................................................................... 54
B.2. Distance Vector algorithm (DV)................................................................................. 54
B.3. Hierarchical Routing algorithm (HR) ....................................................................... 56
Appendix C – Communications Technologies .................................................................... 57
Appendix D – User Interface.................................................................................................... 58
D.1. Textual Input and Output ............................................................................................ 58
D.2. Graphical Input and Output ........................................................................................ 58
D.3. Voice Input and Output ................................................................................................ 59
Appendix E – Storyboard........................................................................................................... 61
Appendix F - System Architecture Communication Links ............................................. 62
Appendix G – Use Cases............................................................................................................. 63
Appendix H – Activity Diagrams ............................................................................................. 64
Appendix I – State Charts......................................................................................................... 74
Appendix J – Classes and Relationships.............................................................................. 76
Appendix K – Front End Design............................................................................................... 78
K.1. Initial Location Search Screen ................................................................................... 78
K.2. Location Confirmation Screen .................................................................................... 79
K.3. Map Screen ........................................................................................................................ 80
K.4. Directions Screen ............................................................................................................ 81
K.5. Driving Screen .................................................................................................................. 82
K.6. Warning Screen................................................................................................................ 83
K.7. Final Screen ....................................................................................................................... 84
Appendix L – Algorithm Pseudo-code................................................................................... 85
L.1. A* algorithm ...................................................................................................................... 85
L.2. Distance calculation algorithm................................................................................... 86
Appendix M – Java Classes and Relationships ................................................................. 88
Appendix N – XML how-to ........................................................................................................ 90
Appendix O – XML Design ......................................................................................................... 92
O.1. XML Schema...................................................................................................................... 92
O.2. Network XML .................................................................................................................... 92
O.3. Geometry XML.................................................................................................................. 93
O.4. Data Access ....................................................................................................................... 95
Appendix P – RAID ...................................................................................................................... 96
Appendix Q – Implementation Considerations ................................................................. 98
Appendix R – Network Design................................................................................................. 99
Appendix S – Testing Documentation and Results........................................................ 100
S.1. System White Box Testing Results ......................................................................... 100
Page 3 of 122
S.2. System Black Box Testing Results .......................................................................... 106

S.3. Route White and Black Box Testing Results ....................................................... 109
S.4. Usability Testing Documentation and Results.................................................... 110
Page 4 of 122
1. Introduction
Conventionally, an in-car navigation system is installed in a car to provide route planning

and turn-by-turn information facilities to enable a driver to take the most efficient route
when travelling from A to B, going someway towards replacing traditional paper-based
maps.
The most common way of giving route, traffic and current location information to the user
is through a visual display, with some systems occasionally also having audio feedback. An
in-car navigation system can often cost many hundreds of pounds. Currently, few systems
are able to obtain and use local traffic information, such as speed and flow rate, to help
the driver avoid traffic problems and none upload their data for use by other systems.
The aim of this project is to provide a viable alternative for a user, taking into account
their needs and local conditions to give as economical a journey as possible.
1.1. Concept
The main focus of this project is to take an alternative approach to the concept of
in-car navigation and will try to address two of the key problems with current
systems.
1) It will create a Peer-to-Peer network between different users to allow the

easy sharing of local information including weather, location and road
conditions (including traffic).
2) It will use an interface and feedback mechanism that will reduce the work
load on the driver, increasing safety. This will include voice feedback and
turn-by-turn (TBT) instruction.
The system will be aimed at people who frequently travel long distances over varied
routes by road, such as chauffeurs, taxi firms, delivery firms and salespeople.
1.2. Project Statement
The primary goals of this project are to:
1) Route planning between a particular pair of nodes across a network of them.
2) Develop a system of communication between individual vehicles on the road,

possibly using a central hub to aid in the sharing of relevant information.
3) Demonstrate the use of technologies, that to me are new or relatively

underused, to create functionality within the program:
• Geography Mark-up Language (GML) for mapping
• Global Positioning System (GPS) for location
• Intelligent algorithms for routing
• General Packet Radio System (GPRS) or WiFi networking (802.11b
& 802.11g) or a similar system for communication
Page 5 of 122
• Extensible Mark-up Language (XML) for communications language

and data storage
4) Make a simple and easy to understand interface and feedback system to

reduce impact on users’ concentration, including voice and TBT information.
5) Create a virtual traffic scenario to show how individual clients can make the
best decision given received data, and as a base test with no received data.
Possible secondary goals of this project are to:
1) Add a facility for automated live reports through the web, text message or
email, formatted for use by the public.
2) Allow route planning to take place between a set of nodes (for instance,
from A to B via C).
Page 6 of 122
2. Existing Solutions
This section considers the platforms and systems for in-car navigation. To effectively
review such systems a clear set of criteria must be established to enable consistency
between what can be extremely diverse pieces of hardware and software. Since this
project is focusing on peer-to-peer in-car navigation, this section looks at how other
applications approach the following:
- route planning
- voice feedback
- peer-to-peer communication
2.1. Platforms
There are a variety of systems across a range of platforms for use in-car (including
non-native devices that could be adapted for such use). The most common system
until recently was a portable hardware based solution such as a handheld or
dashboard mounted Global Positioning System (GPS) system; using location
information received through the GPS satellite network, these give basic maps and
directional information on a small screen, for example those shown in figure 2.1.1.
Current legislation has made the use of handheld portable GPS devices by the
driver of a moving vehicle illegal, making properly fitted systems a requirement for
practical in-car navigation.
Figure 2.1.1 – Hardware based route navigation
More recently though, in-car route navigation has become far more advanced and
can now cost many thousands of pounds for a top of the range system with
features including:
- 2D and 3D mapping
- Voice guided navigation and control
- Portability between vehicles
2.2. Packages
It is unlikely that any single piece of software will fit every need of an in-car
navigator, however this section looks at a variety of pieces of software (both car
Page 7 of 122
based and web based) to provide as large a sample as possible. Some combination
of all of the useful features with none of the short comings would be ideal, but this
is the real world of course.
While probably beyond the scope of the project, I believe the ideal compromise
would be some form of voice control and feedback thus removing the need for the
user having to have any physical interaction with the system. During your journey
you would be able to ask for points of local interest, such as restaurants and petrol
stations. This does not yet exist in a tangible form as far as it is possible to
research.
2.2.1. Criteria
For each route finding application a variety of factors will be considered,

including ease of use, interface and feedback type, route finding and
accuracy.
Each application is either commercially or freely available on the web or on

CD. The maximum cost of the applications is around £300, while some are
completely free assuming Internet access is available. To test the
applications two routes were planned, with a longer one from my home town
of Lichfield to Exeter and a second, much shorter one, from my student
house at EX4 6JG to the Computer Science department at EX4 4QF – taking
into account distance and estimated time.
The following features were considered when reviewing each piece of

software:
- Distances and times involved in the example routes

- Route of the drive (including what type of roads it uses)
- How easy to understand the instructions are
- Interface design
Finally the application’s good and bad points and how these relate to the
project were recorded.
Page 8 of 122
2.2.2. Results and Conclusion
The individual reviews on which these results are based can be found in
Appendix A.
Long Routes
Distance and time Route Instructions Interface

Microsoft 187.8 miles in 2 Almost all Fairly complex Laptop based, easy to use
Autoroute hours 47 minutes motorway
and A-roads
ViaMichelin 178 miles in 3 Indirect route Very difficult (the Web based, difficult to
hours 14 minutes using more exact address at the understand
A-roads destination was
“ignored”)
The AA 181.1 miles in 3 Almost all Average Web based, easy to read but
hours 16 minutes motorway basic features
and A-roads
The RAC 184 miles in 3 hours Almost all Very simple Web based, with easy to
13 minutes motorway quickly read turn-by-turn
and A-roads instructions
Tom Tom Unknown Unknown Unknown PDA based, portable
Short Routes
Distance and time Route Instructions Interface

Microsoft 0.9 miles in 5 Direct Average Laptop based, easy to use
Autoroute minutes
ViaMichelin 1 mile in 5 minutes Direct, but Average Web based, map not
inaccurate displayed by default
destination
The AA 1.5 miles in 3 Incorrect and Average Web based, unable to route
minutes vague to specific postcode
The RAC 0.8 miles in 2 Direct Simple Web based, but poor map
minutes
Tom Tom Unknown Unknown Unknown PDA based, portable
Without looking at the route finding aspect, Tom Tom seems the most
similar route navigation tool to the previously described ideal; it has clear
and easy to understand maps and at least has the beginnings of a workable
voice input and output system. Since the interface is a quality design, I will
attempt to model my interface around the design of this piece of software.
However, since the routing abilities of Tom Tom could not be reviewed, the
piece of software that returned the shortest routes was the RAC system. The
difference between each of the evaluated systems, particularly on the long
distance journeys was primarily down to variations in the road taken from
the main roads (such as motorways) to the final destination.
Apart from ViaMichelin all the systems took the majority of the same route.
However, most of the website based systems found it hard to navigate short
distances - this was often due to the trimming of the postcode entered
Page 9 of 122
leading to vague points. For this, Microsoft Autoroute was the clear winner
since it was able to circle each particular location almost exactly.
In conclusion, a system combining the functionality of Tom Tom and

Autoroute and portability of Tom Tom itself would provide for a very useful
and accurate system.
Page 10 of 122
3. Routing Algorithms
To build an effective in-car navigation tool it has to be able to successfully navigate across
a network of points, from A to B. While this project is not concentrating on the particular
methods for route finding it does require one to function. As such, this section will
investigate and select an appropriate algorithm that could be implemented within my
system.
According to Razavi [1], “routers use routing algorithms to find the best route to a
destination”. Since part of this project will try and use some computer based solutions for
real world problems, a network routing algorithm will be implemented for this section of
the project; nodes (such as towns and junctions) and edges (such as roads) will be the
routers, nodes and cabling of my network. An adaptation would have to be made to
account for the fact that there would be no traversal of the network with packets, but
instead with vehicles. Each vehicle’s computer will have a model of the network in its
memory, and based upon data provided by peers will make a best route analysis. Razavi
describes various network based algorithms, which are summarised in the following
sections.
It is important to realise at this stage that there does not need to be a discovery stage for
routing, a stage where “routers” share information about their connections since we can
assume the network (road system) is fairly static in that the physical make-up of the
network will rarely change. In general, the only changes that will be made will be the
weighting of a link (a road over an edge in this case) – one with a high weight is more
difficult to traverse. It will be assumed that the network map in each vehicle’s memory,
containing node and cost information (that is, the speed limit for a given road), is up to
date.
3.1. Standard Algorithms
To discover the best route to every node a variety of different algorithms can be
employed – such as the adapted Dijkstra shortest path algorithm. This algorithm
builds a graph of the network and identifies source and destination nodes; against
this graph it then adds an adjacency matrix which indicates the weight/cost of each
connection. Further details about standard algorithms can be found in Appendix B.
3.2. Intelligent Algorithms
While the standard methods are efficient, they are effectively only brute force
techniques. This means that they check almost each and every route, including
ones that are unlikely (for example, a route across Exeter which would travel on the
motorway). There are, however, a multitude of Artificial Intelligence (AI)
techniques that could be suitable for this project.
Looking at past projects [2] using route finding technologies it became clear that
there was some success using the technique called the A* method, developed by
Patrick Henry Winston.
Page 11 of 122
- Form a one-element queue consisting of a zero length

path containing only a route node.
- Until the first path in the queue terminates at the
goal node or the queue is empty:
Remove the first path from the queue; create new
paths by extending the first path to all the
neighbours of the terminal node.
Reject all new paths with loops.
If two or more paths reach a common node, delete
all those paths except the one that reaches the
common node with the minimum cost.
Sort the entire queue by the sum of the path
length and the lower-bound estimate of the cost
remaining, with the least-cost paths in front.
- If the goal is found, announce success; otherwise,
announce failure.
Figure 3.2.1 – Algorithm for A* [3]
The A* technique is a more refined version of the Distance Vector (DV) and
Hierarchical Routing (HR) techniques described in Appendix B, taking into account
the geographical locations of each node, thus speeding up the process (for
example, the algorithm will not try and head away from the destination).
3.3. Dealing With Changes
While these algorithms are easy to compare when considering a static network, the
situation becomes more complicated when taking into account the issues raised by
the specification of the project – namely that the route finding system should be
able to divert around traffic and other similar problems on the roads when notified
of such conditions by other vehicles.
It is important to remember that regardless of what happens to the network, nodes

and connectivity will normally not change; the only factor that will change is the
weight of each link (the ease of traversing it). Should a new ‘road’ be added to the
network, a new dataset would need to be downloaded to each client, in the same
way that Microsoft Autoroute’s network is only updated with each new release.
A solution is to work on a local level (to that of the obstruction) and for the
purposes of the algorithm exclude the wider area. Changing a link to make it have
a high or infinite weighting, the A* algorithm will need to be restarted and will treat
such a link as unviable thus recalculating a new route until the path of the old route
is resumed (at which point it can follow the earlier, original calculated path).
3.4. Conclusion
Research on the subject [4] has shown that a combination of pre-calculated routes
(for long sections of a route, such as a motorway) and on-the-fly routes (such as a
cross-city route) works fastest.
Page 12 of 122
With this in mind, in my opinion it will be best, at least at first, to attempt to

implement the AI method to calculate all routes then implement some form of
‘route caching’ if subsequent calculations prove slow for the size of the planned
network.
Page 13 of 122
4. Communication Technologies
One of the goals of this project is to implement a form of peer-to-peer communication

between different cars on the road to enable the sharing of local road and traffic
information. To implement this some form of data needs to flow between the vehicles and
the aim of this section is to investigate how this might be achieved, first looking at
technologies then looking at the languages of the messages.
4.1. Medium
There are many ways for two peers to exchange information:
- WiFi (Wireless networking)

- GPRS (General Packet Radio Service), 3G (the de-facto mobile standard)
or GSM dial-up (Global System for Mobile communications)
- FM radio (Frequency Modulation radio)
- CB radio (Citizen Band radio)
To choose the best technology, requirements for this project need to be clarified.
Since one of the main ideas of the project is to enable the peer-to-peer
communication of mobile devices to describe road and traffic conditions, a group of
systems must be able to communicate:
- directly (or at least through a third party messaging system)

- over relatively long distances (one or two miles at least, to make
forewarning of traffic worthwhile)
- efficiently (not necessarily fast, but enough for short messages without
any extraneous traffic)
- reliably (connections must work over much of the road network)
Further details of each can be found in Appendix C.
From these options, GPRS is the most suitable for this project - each service has its
own characteristics which include many drawbacks. GPRS seems like the most
logical and cheapest solution for this project. While during development this project
will not be using GPRS directly, it will be written to ensure that it can be deployed
without any further coding or configuration.
4.2. Language
Given that the GPRS does not intuitively allow for direct messages, a way of
connecting through a messaging service is required. The easiest way to download
data with GPRS would be to use standard HTTP traffic, more specifically XML.
With this service, the in-car system would be able to send and receive data relating
to traffic and local travel information to and from other vehicles. For each peer to
send and receive messages a separate ‘Message Centre’ would need to be created
to get around the inherent problem with a GPRS connection – this could just be a
page that is refreshed by the peer over and over again. Using a server-side
Page 14 of 122
technology such as JSP or PHP, the data could be dynamically generated given the
data from other peers. An example of how this might work:
Peer 1 Peer 2
Messaging service
Peer 5 Peer 3
Peer 4
Figure 4.2.1 – Example of the messaging service set up interface
Given this, it was possible to form an example of how a message might take shape:
<?xml version="1.0"?>
<warnings>
<%= new MService.getMessagesForClient(“1”) %>
</warnings>
The call to the getMessagesForClient method in the middle would generate data as
required by the peer. Returning information to the messaging service could be
achieved by passing data along with the page request, for example:
http://mservice/page.jsp?client=1&road=M6&speed=10
Here, client “1” is reporting slow traffic on the M6. These two parts when combined
will enable two way communications between individual peers. Using data received,
each node will make its own decisions on how best to avoid traffic problems, if at
all.
Page 15 of 122
5. User Interface
This section will explore the different methods for a user to get data into and out of the
system. Given the stringent laws of the United Kingdom regarding the use of mobile
phones while driving, one of the main interests while developing the project is to reduce
the amount of energy a user needs to put into using the system while driving,
concentrating on the road.
Any system for input and output needs to be:
- quick to read
- easy to understand
- viable to deploy and implement
The individual details describing the elements of the user interface details can be found in
Appendix D. As stated in the conclusion of the ‘voice output’ section, I would like to aim
for a hybrid system, adopting one or the other if this is not possible. Given that voice input
is relatively difficult to build into and use with a system it will not be pursued any further.
Given this, the project will use the following:
- voice output
- graphical input (in part) and output
- textual input and output
Each method has its own benefits for the user of the navigation system, and as with any
application only combining them will meet the goals of the project.
Page 16 of 122
6. New Technologies
This section looks at technologies that have little perceived use in this context and ones
with which I personally have little experience. In spite of this lack of knowledge on my
part, I will not be trying to implement technologies that have no relevance or place within
my project – only ones that help me complete the objectives of the project.
6.1. Geographical Mark-up Language (GML) for mapping
GML [5] is a new language, based on XML, for defining and storing geographical
data. GML and XML allows for free form data with less strict constraints than a
Structured Query Language (SQL) database. This will be useful in this project
because changes are likely to be made to the data format required as the system
develops.
As there are many different programs that work with graphs a way of exchanging
data was developed by the Open GIS Consortium. GML supports attaching arbitrary
information to graphs, nodes and edges. The language is clearly specified allowing
inter-operable development to take place. The following is an example of a single
road from a sample network devised for this project:
<gml:featureMember>
<Road rid="r19">
<gml:name>A115</gml:name>
<avSpeed>60</avSpeed>
<gml:directedEdge xlink:href="network.xml#e19"/>
</Road>
</gml:featureMember>
Figure 6.1.1 – GML example
GML in a route finding application could be used for a number of different reasons.
The language would be able to define nodes, such as motorway junctions and their
interconnecting roads. This is where the clear benefits of the language are shown,
using additional tags within the GML, further information about each section could
be added including, for example, the average road speed or whether the road is
one way or not.
Besides the language itself, there is a large support network of people and
organisations supporting it. One in particular is the University of Leeds who have
played a founding part in the development of the Geotools project. This is a suite of
utilities, developed in Java, that enable features related to GML including graphical
display and data manipulation [6].
It is important to note however, that while GML is efficient for storing the network
on disk, this cannot be said for random access (from Java on-the-fly) – this would
be far more efficient from system memory. Once the application is loaded, the GML
data would be imported directly through GeoTools and additionally processed with
a secondary XML / Document Object Model (DOM) reader (to access meta
information relating to the GML, such as details of towns and junctions). This would
then be transferred into a suitable data structure in Java and used from there.
Page 17 of 122
Project points: The language is very adaptable and would be able to hold all the
information that is required for the network in the project. Since the A* routing
algorithm requires geographical information for calculating remaining distance, the
additional parameters of GML would seem to provide a valid solution to the
problem.
6.2. Global Positioning System (GPS) for location

Field Example Comments
Sentence ID $GPGGA
UTC Time 092204.999 hhmmss.sss
Latitude 4250.5589 ddmm.mmmm
N/S Indicator S N = North, S = South
Longitude 14718.5084 dddmm.mmmm
E/W Indicator E E = East, W = West
Position Fix 1 0 = Invalid, 1 = Valid SPS, 2 = Valid DGPS, 3 = Valid PPS
Satellites Used 04 Satellites being used (0-12)
HDOP 24.4 Horizontal dilution of precision
Altitude 19.7 Altitude in meters according to WGS-84 ellipsoid
Altitude Units M M = Meters
Geoid Seperation Geoid seperation in meters according to WGS-84 ellipsoid
Seperation Units M = Meters
DGPS Age Age of DGPS data in seconds
DGPS Station ID 0000
Checksum *1F
Terminator CR/LF
$GPGGA,092204.999,4250.5589,S,14718.5084,E,1,04,24.4,19.7,M,,,,0000*1F
Table 6.2.1 - Example of a decoding table followed by an example sentence
GPS [7] is a satellite based navigation system developed, funded and controlled by
the United States Department of Defense (sic). While there are a large number of
civilian users across the world, the system is and was designed for use by the US
military.
Data from specially coded satellite signals can be processed by a suitable GPS
receiver giving computed position, velocity and time. Four ‘fixes’ are required to
compute position in three dimensions, with the fourth giving a time offset for the
receiver’s built in clock.
Once a fix has been made, the GPS device is then able to output this data over a
serial link to a computer. The standard protocol for this is called NMEA (National
Marine Electronics Association) 0183. The data format is relatively basic and
consists of bursts of data every two seconds or so.
Project points: In this project I would like to give each client/peer GPS data so that
vehciles can obtain their location as they travel along and the route finding system
Page 18 of 122
knows how they are proceeding with the planned route. While it will be impossible
to use real GPS data in my system (since most of the development of the system
will be indoors) it would be possible to create a small application that creates virtual
GPS signals for use in the system.
However, it may prove easier for each client to assume it knows where it is based
on inertial sensors (for example, road speed and turning). In a real world example
though, the GPS would need to be there since inertial sensors are not entirely
accurate and require a fix on their initial location to function.
6.3. Conclusion
While writing this report I have experimented with GML, developing a test network
and obtaining and implementing Java based parsers. Given the description of the
language it is perfectly capable of handling the data structure required for this
project and as a result I will be implementing it where required throughout the
project.
Since I am intending to develop the majority of this project “in the classroom” it will
inevitably be impractical to use GPS in this project since it relies on line-of-sight
with several satellites. While it would be possible to create an emulation system as
the GPS data with simple text commands this will be rather academic since the
modelling of vehicles in a virtual traffic scenario will inherently require knowledge of
their locations. As an alternative I will create a GPS data logging module, the data
from which could then be loaded into other suitable applications for viewing.
Page 19 of 122
7. System Requirements
As a result of research discussed in section 2 to 6, the following requirements have been

compiled.
Primarily my system will meet these requirements:
1. The system must store and access a large (>50 nodes) GML network.
2. Route finding must allow a vehicle to cross the network from a start node to an end
node.
3. Each vehicle must share traffic and road information with all other vehicles.
4. Given a local road problem a vehicle must be able to automatically give new directions
around the obstruction at the user’s request.
5. Each vehicle system must provide verbal feedback of directions, traffic and on-screen
dialogs.
6. Textual and graphical data must be kept to a minimum when the vehicle is in motion.
7. Each vehicle must accept a NMEA 0183 data stream from a suitable GPS device for
location information.
8. Communication between vehicles must be able to take place using GPRS.
9. The graphical output / display must be suitable to fit that of a 3-4” PDA.
10. A graphical map must be displayed for the user before a journey starts with optional
detailed TBT information.
And given enough time I shall attempt to meet these further requirements:
1. Provide web, mobile and email based data to visualise traffic and, where relevant,
vehicle locations.
2. Allow the selection of intermediate nodes on route.
3. Add an administrator’s interface for the network, to allow it to be updated within the
system.
Page 20 of 122
8. System Architecture
Vehicle - Front End
User Interface
(1) (2)
Vehicle - Back End Message Centre
Java Bean
(3) (4) Message Handler
Vehicle System (22)

(10)
Routing (9)
Sub-system
(11)(12) (7) GPS Logging

Process
Route Finding (26)
(23) (21)
Algorithms (5)
(8) Messaging
(20)
Sub-system
(13) (14) GPS

(24) Logging
(25)
GeoTools Middleware (6)
(15)
XSD (XML
(16) Schema
Definition)
(17) (18) (19)
GML
GML GML
Geometry
Network Geometry
(live)
Simulation
Vehicle
Simulation
System
Figure 8.1 – System Architecture diagram
The diagram figure 8.1 shows of the anticipated system architecture based on the
requirements of section 7 and storyboard in Appendix E. Definitions of numbered links can
be found in Appendix F.
Page 21 of 122
9. Formal Backend Modelling
Primarily the object-orientated Unified Modelling Language (UML) was used to model the
structure of the backend portion of the system. UML is a graphical and textual language
for the creation of system models based around formal object-orientated design and used
across the software development industry for the formal definition of software models.
UML was used for this project because, using freely available software tools, it helps easily
specify, visualise and document software system models.
UML is a method for visualising software in multiple dimensions and levels of detail.
Software is often, at least initially, very abstract and hard to visualise. As such, a
modelling language such as UML allows a system to be fully understood before the
lengthy process of coding begins. Poor design documentation reduces the value and
transferability of software and so therefore modelling is very important.
UML has many advantages over other modelling techniques: for instance, it can be applied
to many areas of software development; it is extensible and therefore flexible. It is use
case driven and as such ensures it is possible to trace a design back to that of the original
requirements for the software. With each diagram, the backend model is expressed in
increasing detail - the data describing each diagram (generated by tools such as Microsoft
Visio) is then stored in XML, although in this report, the diagrams themselves are the most
important.
This is the point in the project at which the majority of the backend of the system is
designed. These diagrams demonstrate how modules interrelate and how data is stored
and passed between them.
9.1. Use Cases
Use cases define “the behaviour of the system from the users’ point of view” [8].
While they do not explicitly make any particular reference to internal processing or
data within the system, it is possible at this point to establish what a system would
need to do to meet the use cases diagrammed.
In the use case diagrams, found in Appendix G, there are two main groups of use
cases. The first are ‘user controlled’ and are effectively the tasks that the user, by
way of the original specification for the project, needs to complete. Second is the
group of system/time controlled tasks such as messaging or logging which again,
are required by the original system specification.
9.2. Activity Diagrams
Following on from each use case, a collection of activity diagrams “records

preliminary ideas about internal processing (and data)” [8] within a system. UML
Activity Diagrams are the formal object-orientated equivalent of flow charts and
allow the flow of data within a system to be visualised. While the majority of
operations modelling is simple and consist of few words, it is still useful to map
each individually to avoid any confusion by people reviewing or working with the
project. Activity diagrams demonstrate the dynamic behaviour of the system over
time and the flow of control between the user and system.
Page 22 of 122
The activity diagrams can be found in Appendix H.
9.3. State Charts
While State Charts are now known as ‘State Machine Diagrams’ in the new UML 2
specification, they are still in essence the same thing. All objects have behaviour
and state, “in other words, they do things and they know things” [9]. Some objects
can be extremely complex and, as such, developers can have difficulty
comprehending every possible situation in which an object can exist.
UML State Charts aid in this understanding by depicting the various states that a
group of objects (or system) can have, and the transitions between those states. A
state represents a step in the behaviour of a particular group of objects, and as
with the earlier Activity Diagrams it has a start and end state (represented by the
full circle and double circle respectively). A transition represents what event or
action needs to occur to cause a change to the next arrowed state.
Some objects within the Traffic:Live! system do not require state charts, such as
the location object because once created their data and state remains static.
However, other more complex objects (or combination of objects) do require their
state to be modelled to adequately demonstrate the functioning of the object.
These objects are the ones that provide the primary functionality of the system, for
instance the routing state chart relates to an amalgamation of the objects
highlighted in the ‘create new route’, ‘get directions’, ‘avoid problem’, ‘drive’, ‘search
route’ and ‘get map activity diagrams’, among others.
As a whole, a state chart effectively represents the transitions and states for each
activity diagram. The main difference between an activity diagram and a state chart
is that in an activity diagram events occur in the boxes, whereas in a state chart the
opposite occurs with events happening in the transitions.
The State Charts can be found in Appendix I.
9.4. Class and Relationships
In the class model, the Vehicle class relates to the Vehicle System of the System
Architecture.
Class diagrams have long formed the basis for much backend design. They show
the classes of a system, their associations and in this case the attributes of each
one. The primary purpose for creating a class model is to explore the domain of a
system, which is the internal ground for the system. In an individual class box, the
first portion is the name of the class, the second shows the attributes and the third
the methods, although this final portion is not used in the class model for this
project.
A class structure is constructed by analysing the previous activity and state

diagrams. The key importance is to ensure that all required data is covered in the
class diagram to satisfy the operations that take place in the transitions and
Page 23 of 122
operations of the earlier diagrams. For instance, the data obtained at the ‘user
entering data’ transition from the ‘State Chart – Routing’ diagram matches the
startName and endName variables from the Route class.
Secondly, the class structure functions as a formal object-orientated definition of

the system architecture from section 8 and relates the classes from the class
diagram to their communication and layout within the systems that form
Traffic:Live!. For instance, a Route class is used by the routing sub-system to form
the correct data to pass to the route finding algorithm found in the system
architecture.
The class models can be found in Appendix J.
Page 24 of 122
10. Front End Design
Front end is a crucial aspect of software design and development. For the majority of the
time it is the only part of software that an end user will see, and for the whole of that time
it is the only part a developer will want them to see. If only a small amount of work gets
put into the User Interface (UI) then it can let down the rest of the program.
Using the interface created through the backend design of section 9 (namely the Use Case
diagrams that describe the functionality of the system from the users point of view), a
front end is established that allows the user prescribed interaction with the backend to
directly meet each Use Case. Further to this, it is important to consider the following
during front end design:
- usability (effectiveness and flexibility)

- interactions and controls
- dialogs and feedback
10.1. Design
These mock screens, based on the original storyboard (Appendix E), have been
designed in HTML, with the intention of using additional Java additions to do data
input and output creating what are known as JavaServer Pages (JSP). The rationale
for using HTML/JSP is simple; it is extremely light and makes the front end an
extremely thin client, reducing the load on the client side since all of the work is
done in the back end.
Since the idea behind the project is for an in-car navigation system, the system
itself has to be small. While there is no specific requirement to run on a PDA style
device or a traditional form-factor desktop machine there is an assumption that the
screen will be mounted on the dashboard. As such, these mock screens have been
designed with this in mind, keeping the size of the window to a minimum (290x420
pixels without the space for page shortcuts at the top).
To provide help to the user, a simple “roll-over” approach will be

taken on all page components, as demonstrated in figure 10.1.1.
For instance, if a user is unsure of the function of a particular
button or field, moving the mouse over it will make a small
window appear describing what the action of the button would be
if it was clicked.
Figure 10.1.1 – Roll-over The green and red buttons seen in each screen are there to
example
simplify the interface, and are designed to be highly visible and
easily ‘pointable’ by someone using a touch screen. Generally a
green button has a positive action (such as advancing to the next screen) and the
red button a negative action (such as resetting the current form).
Descriptions of the individual design for each page can be found in Appendix K.
Page 25 of 122
10.2. Programming
JSP technology allows regular HTML to be mixed with dynamically generated

content retrieved through a JavaBean (linked to the backend system). Once
written, the back-end and JSP files will be deployed to a web application server,
which in this case will be Tomcat 4.
Although in a real deployment, each vehicle will have its own local instance of
Tomcat and will be an entirely separate entity from every other vehicle, there still
needs to be the concept of sessions within the JavaBeans to ensure that the data of
each vehicle (such as the Network and associated Warning objects) do not interfere
with each other. Sessions allow each client to be serviced individually by the
application server and are identical to the concept of instances in Java.
In essence, the presentation layer has been separated from the content layer
allowing for easy project management – this is shown clearly in figure 10.2.1. The
JSP/JavaBean combination allows for full portability behind the scenes, and is
almost entirely server-side, keeping the work performed by the client to a
minimum.
Presentation Layer / Client Tier

-User interface to the system, based in HTML/JSP
-Uses Internet Explorer typically as client application.
Content Layer / Business Logic Tier

HTTP -Java backend, proving JavaBean interface for front end interaction.
-Running on instance of Tomcat.
Database Tier
Geotools -XML datasource storing network.
Figure 10.2.1 – Multi-tiered system
10.3. Input and Output
To satisfy the requirements 5 and 10 in section 7, the software must be able to

generate an on-screen map showing the route calculated by the routing algorithm,
and must also be able to provide spoken directions.
MultiMap.com is an online mapping agency; they provide detailed mapping based

on location information such as postcode, or longitude and latitude. MultiMap
provides requested maps in a web page, next to advertising, short-cuts and logos.
To use these maps within the Traffic:Live! live application a method will have to be
created to automatically request the web page containing the map’s image, then
parse the HTML to obtain the direct image URL.
Page 26 of 122
Using a locally hosted servlet it will be possible to forward requests based on

longitude and latitude to MultiMap (or in fact, any other mapping agency) through
the vehicle’s GPRS connection (discussed in section 4.1) and receive an image in
return, output to the browser through the servlet’s response variable. To break
down the HTML, the servlet will simply need to read the data from MultiMap line by
line until the one with the reference to the map image is found, this can then in-
turn be retrieved and returned to the original browser.
During project research it was decided to use pre-recorded speech synthesis for
output. The functionality for speech will form part of the vehicle class, and since it
merely consists of a minor service class organising files into order, and the
subsequent playing of digital wave files at the appropriate time it requires no
addition to the system class structure (in effect, the code to produce the sound will
be hard-coded into the system).
When an on-screen message is generated. an appropriate combination of sound

files will be played at the same time. While the intention is for the sound to be
audible through the car speaker system through a tape adaptor or mini-FM
transmitter, in the laboratory environment a pair of basic speakers will be
adequate. The developmental process is simple in that as soon as an on screen
message is created during coding an appropriate message is recorded. For
example, a selection of on-screen messages might be:
“Birmingham”
“Travel forward half a mile”
“Turn left in 2 miles”
“Take the A15 at the junction in 1 mile”
These phrases will be broken down into their unique parts and only the individual
words recorded:
“birmingham”, “travel”, forward”, “half”, a”, “mile”, “2”, “1”, “turn”, “left”,
“take, “the”, “a15”, “at”, “junction”, “in”, “miles”
The locations of these files would then be combined on-the-fly to generate a play
list of the complete sentence. This way the amount of audio that has to be
recorded for further directions is reduced since it is likely that at least some of the
audio required has already been recorded. The most efficient way to store these
files would be in a single directory as compressed MP3 files, thus building up a
system vocabulary. Using some hidden object code in HTML, the generated play list
could be loaded by a Windows Media Player applet which would be invisible to the
user.
Given time, it might also be possible to introduce the possibility of adding a user or
manufacturer selectable voice, so depending on preference a female or male could
be heard. This might allow more flexibility in the markets that Traffic:Live! could be
sold in, where some cultures prefer a particular type of voice.
Page 27 of 122
11. Algorithm Design
Various algorithms are required within the project to dynamically create data at run time
that would be too expensive to manually create at coding time, or would be impractical
because of dependencies on external real time data. The primary use of algorithms here is
to generate route information between the various towns and junctions (nodes) on the
road network.
The pseudo-code for these algorithms can be found in Appendix L.
11.1. A* Routing Algorithm
Using the research of section 3.2, a detailed piece of sample code for this algorithm
was generated. Once the algorithm has finished calculations, the final route
between the start and end node can be calculated by recursively asking each node
from node_current until node_current = node_start what its parent is, generating a
series of nodes that represent the valid route.
11.2. Distance Calculation Formula
The distance been two locations in latitude and longitude form cannot naturally be
calculated. As such, conversion between that form (as used for the location of the
nodes and vehicles) and Cartesian form (for the calculation of distance between
nodes) is required for the calculation of G, the estimated cost to goal portion of the
A* algorithm.
Using the code from ZipCodeWorld [10] as a basis, it was possible to develop a
piece of Java code to perform the calculations. The main distance method takes
two GPSInfo objects as variables, and returns the distance between the two
locations in statute miles, with the additional ability to return the distance as
kilometres or nautical miles.
Page 28 of 122
12. Network Design
A database of some form is required to store the data that is used to construct the
network that will be traversed during route planning. This database will be accessed
during node searches and algorithm executions. Since section 6.1 in earlier research
described the use of GML for storing the network for this project, this is what will be
implemented at this stage.
Once the data has been accessed the fastest way to store them is in the vehicle system
memory – this will provide the fastest method of access for the routing algorithm in
section 11. While the class diagrams described in section 9.1 provide clear information on
the abstract internal functionality of the system, this cannot be directly implemetnted into
a Java class structure. As such, further class diagrams are required to show the difference
between the planned and realised systems – these can be found in Appendix M.
It would be possible to obtain any of the system XML files from a source other than the
local hard disk, so theoretically it could be hosted by a central agency and downloaded
each time a vehicle starts. This would ensure that the most up-to-date network is used by
each vehicle. However, in this case, these files will be stored on each vehicle’s Traffic:Live!
system on the individual machine hard disk in a static format (and will be maintained
between system crash/reboot). An XML ‘how-to’ for this project can be found in Appendix
N and the design for each section of XML files can be found in Appendix O.
Page 29 of 122
13. Messaging and the Global Positioning System (GPS)
This is the Peer-to-Peer process of the system - sending and receiving updates on the
state of the network to and from other vehicles. While it was established in section 4 that
direct communication would be impossible because of protocol issues, a simple Message
Centre will be created as a servlet that will pass on relevant updates (that is, on any of the
roads over which the requesting vehicle will be travelling). The Message Centre will be
hosted in a central Internet accessible location, running on another instance of Tomcat
independent of the vehicles.
13.1. Message Format
The format for these Warning messages will be basic XML, and will allow for any
number of warnings to be returned by the Message Centre for each request. This
simple style of communication has the benefits of being reusable for the purposes
of simulation. The Message Centre will automatically remove old messages after a
set period of time (10 minutes for warnings for example).
Since these are short messages, created as required, the simplest way to describe
them is to use a diagram that shows how the Warning object described in the Java
class diagrams found in Appendix M is converted into XML. Based on the example
XML found in section 4.2 of earlier research, the resulting and repeating XML is
shown in figure 13.1.1.
<warnings>
<warning vehicleId=”1” edgeId=”1” roadName=”M6 Toll”
startEndDirection=”true” newSpeed=”10.0” date=”22
January 2004”>
…
…
…
</warnings>
Figure 13.1.1 – Warning(s) XML
13.2. Message Sending
While traversing a section of road, the vehicle system will generate a history – a
combination of speed versus location over two seconds intervals (the same
frequency as a GPS output). This effectively details the condition of the roads that
the vehicle has just travelled upon.
Every minute, if there is at least a 10% variance in recorded speed against the
speed limit of a road a new Warning object will be created and passed as a URL
request to the Message Centre. The Message Centre will decode the request, and
rebuild the Warning object, storing it in a list. This will be done in turn for each
message waiting. In addition, the server will store the time of message delivery, to
allow for expiry of old messages within the server.
Page 30 of 122
13.3. Message Receiving
In a reverse of the process of message sending, while progressing along a route a

vehicle will make a request to the Message Centre and retrieve warnings relating to
all edges the vehicle will be traversing. Passing the id of the edge to retrieve, the
Message Centre will return a collection of messages that are relevant to the
vehicle’s path. All messages will be stored, but only messages that are relevant to
the vehicle’s next road will be used.
This is the point at which the Speed Threshold, specified on the search page of the
User Interface, comes into play. While all messages received are stored in the
system, they are not acted on until the average speed of warnings, relevant to next
road to be traversed, drops below this threshold. At this time, the local messaging
sub-system notifies the vehicle system which then in turn notifies the user. Should
the user choose to ‘accept’ the warnings, the system will then create a new route
from the current location taking into account the warnings in the database, thus
avoiding the traffic problem.
13.4. Integration into network
As the data being passed through the Message Centre is merely an XML
representation of Warning objects, this allows it to be easily reconstructed when
received by a vehicle and then stored within that vehicle’s network. Each Warning
object can then be accessed by the routing algorithms should the user wish to
divert around a traffic problem.
13.5. GPS
To allow the application to talk to an attached GPS device, a package called

JavaGPS is called, developed at the International University in Germany. Although
as with GeoTools, the package provides a great deal of functionality the primary
use for this package will be to automatically generate new GPSInfo objects every
time a new location is read from the GPS device.
For this project, the primary class GPSDriver was customised so that it could also
accept simulated GPSInfo objects required for demo purposes. An external object
such as the vehicle extends the GPSListener object from the JavaGPS package, and
then it creates a new GPSDriver object specifying where to obtain data (either a
COM port or a simulation), finally registering with the GPSDriver object to receive
updates when new data is available.
Every time new data is received, the GPSDriver generates a new GPSInfo object
and passes it to each registered listener, at which those listeners can then act on
the data.
Page 31 of 122
14. RAID
RAID (Risk, Assumptions, Issues and Dependencies), a form of due diligence, is a way of
finding and mitigating the issues that form part of project development and
implementation in particular.
A risk is a source of danger to the project.
An assumption is something that is assumed to be true during the project development.
An issue is an important, unresolved, question in relation to the project.
A dependency is something that is relied upon for the completion of the project.
There are five key steps in the process of creating a comprehensive risk management plan
for a piece of software development:
1. Issue identification
This is the process of systematically identifying all possible events which may
impact a project. In this case, this takes place by reviewing design documentation,
developer history, and studying future work plan breakdowns.
2. Issue quantification
This is the product of two variables:
• Issue Probability:- an estimate of the probability that the given issue will
occur.
• Issue Value:- an estimate of the gain or loss that will be incurred if the issue
does occur.
3. Issue qualification
This is rating of the issue, its importance:-
• High:- likely to cause significant impact to things such as time scale, cost,
scope or quality.
• Medium:- potential to cause some impact.
• Low:- little chance of causing impact.
4. Issue response
There are many ways to address identified issues:
• Avoidance:- Eliminate, ideally through the cause.

• Mitigation:- Minimizing impact.
• Transfer:- Delegation of tasks, and as a result, risk.
• Retention:- Accepting impact.
Page 32 of 122
5. Issue control
This details the procedures that will be used to manage risk.
Together these processes help to ensure that project implementation can take place
smoothly with no surprises. These identified issues will also impact later testing, since
testing will demonstrate if these issues have been adequately covered.
Identified issues, with issues that are key to the project given extra time in the project
development plan and highlighted in italics are shown in the table in Appendix P.
Page 33 of 122
15. Implementation, Simulation, Demo and Testing
The purpose of software testing is to evaluate and assess the quality of work at each
stage in a piece of software development.
15.1. Implementation Considerations
During development a ‘change log’ was maintained that described any significant
changes between the planned and implemented systems. This log can be found in
Appendix Q.
15.2. Simulation for the Demonstration and Viva
Since this project is primarily intended to be an “in-car” navigation system it poses

a unique problem when it comes to providing useful demonstrations for the
purposes of the project viva. Since the viva itself will be taking place at an indoor
location this means that it will not be possible for two fundamental parts of the
system to function without modification, being the GPS (requires both vehicle
movement and a line-of-sight with the satellites in the sky) and the actions of other
drivers on the vehicle with the navigation system.
To get around these significant problems, two extra ‘simulation’ modules were
added to the system. It is important to note though, that in an actual deployment
of the system, the simulation system found in the original system architecture
diagram from section 8 would not exist and would be replaced by real
environmental data (that is, data from a real GPS device).
The first module generates an artificial GPS data stream based on the vehicle’s
current route and feed this through the same mechanism that data from a real GPS
device would take. To the system, this data will be identical in source to real data.
The simulator thread will execute every 2 seconds (the same frequency as that of a
real GPS), allowing the vehicle to react as originally designed to received data.
The second module will simulate the reactions of the driver and vehicle to other
vehicles. Initially while vehicles pass over the network they will travel at a road’s
speed limit. For the purposes of this project, road classifications and speed limits
have been assigned to the network design in Appendix R.
When driving on a road, a driver does not simply have the road to him or herself –
they also have to take into account other drivers slowing down for instance when
there is heavy traffic (as we are simulating in this project).
To simulate the slowing down effect of vehicles on the network it was necessary to
simulate ‘awareness’ of other vehicles in the vicinity of a particular car - to
accomplish this a further Simulation object was created (similar to the Warning
object). Methods for transmitting and receiving Simulation objects, via the Message
Centre were also be exactly the same as for Warning objects.
Page 34 of 122
For every Simulation object that a vehicle receives, it will reduce its speed by 10
mph from the current road speed limit, to a minimum of 10 mph. As more vehicles
travels along a road, their average speed will also drop.
15.3. System White Box Testing
Using the system architecture tree structure as a basis, the order the main
components of the system were tested (and built) was:
• Network and Geometry XSD and XML files

• GeoTools data reading and writing
• Route finding algorithms
• Routing sub-system
• Vehicle simulation
• GPS logging
• Messaging handler (Message centre)
• Messaging sub-system
• Vehicle system
• User Interface
Much of the code in this project, while not overly complex, is based heavily in what
were relatively unfamiliar data languages to me (such as XML, NMEA) and uses a
lot of mathematics (routing and distance calculation). Because of this,
comprehensive white box testing needed to take place, during and after
development.
Static analysis
Crucially, code did not need to be able to run to be put through this stage of
testing. The best approach to static analysis is to use the Fagan Inspection [11],
developed by Michael Fagan a developer with IBM in the 1970s. Principally, this
consists of frequent meetings of a team of developers to review code produced and
to try and highlight errors early before they become a major problem.
The Fagan system is a complex process involving entry and exit criteria, code
improvement, incident logging and error resolution and eradication. The following
plan is loosely based on his ideals. By looking for errors, omissions and
complexities, the Fagan approach ensures code is:
- correct (i.e. it works)

- meets the original project specification
- maintainable
The aim of the meetings is not to solve problems, but merely to identify them.
Minutes of discussions at each meeting, detailing faults or incidents found, are
essential to ensure that information discovered in the meetings is not forgotten and
an example of the form used can be found with the subsequent results in Appendix
S. From these minutes an action plan can be produced detailing the crucial parts of
the code that are satisfactory and those that need review.
Page 35 of 122
Since this project was coded solo, it was impossible to conduct formal meetings
with a team of people related to the project involved in the review. However, since
the development was part Department of Computer Science it was possible to
occasionally call on other students for their informal assistance at this stage. Once
the first piece of code development had begun, meetings were scheduled to take
place (sometimes with another student) to conduct reviews as above on a module
by module basis until the final system was completed.
Figure 15.3.1 – Jtest user interface
Further to this manual analysis, automatic testing tools such as Jtest (by Parasoft)
were used (see figure 15.3.1). Jtest is a dual static code analysis and dynamic unit
testing environment for Java. For the purposes of static code testing, Jtest has a
large selection of built-in rules that when applied to the code developed for this
project allowed for rapid identification of simple faults such as code layout or poorly
written comments. Run on the same regular basis as review meetings, making logs
of errors, these ensured a thorough evaluation of code during development.
Secondly, an ‘XSD Schema Validator’ [12] was used to validate the XSD files was
used to ensure that the XML files in the project were accurate. This tool simply
takes an XSD file, an XML file and the URI for the namespace (the basis of the
schema, in this case: http://www.opengis.net/app) and returns a list of errors
which can then be manually fixed.
Another important step of this phase of testing was to manually select a test data
set for each component. Using the knowledge of methods and modules gained from
coding and subsequent code review, it was possible to select values that will
appropriately test each section of the system. While at this stage, the components
themselves were not actually tested, this discovery of expected results (and
entering into a table) was important, since these became important when black box
boundary value analysis began.
Page 36 of 122
Dynamic analysis
Dynamic analysis uses test data sets to execute components and software as a
whole in order to observe their behaviour and produce test reports. Effectively, it
explores the semantics of the application under test conditions with tests that are
likely to cause problems with the components.
As with the static analysis of the development, Jtest was again used at this stage.
Jtest automatically analysed each component of the system and created tests that
at first, executed all portions of code (reporting any that are not executed) and
second, highlighted any code that might have caused unidentified exceptions.
These tests were then run across the entire system, with Jtest logging exceptions
and errors generated. Any errors found were then corrected – and as such only
these are mentioned in the results.
15.4. System Black Box Testing
The second major step in functionality testing is to test each component and the
complete system as a black box, that is the software is tested with no reference to
the internal coding of the component.
Value analysis is a test case design technique for an individual component where
test cases are designed to test the outputs of methods for their accuracy with the
given values – this is done using the table in Appendix S and the selected values.
For instance if a field is required to “accept integers between 20 and 100 inclusive”
the values tested might be:
20
100
19
101
null
The first pair of integers test the inner-boundaries, where those that should be
accepted are 20 and 100, then the outer-boundaries, where those that should be
rejected by the component are null, 19 and 101 since they do not meet the original
requirements of the test.
If, when tested in the black box scenario, a system performs as expected and
rejects the appropriate values then the component is deemed to have passed that
test. Tests were conducted for each component and test data chosen when
completing the test plan from the earlier white box static analysis.
15.5. Routing White and Black Box Testing
While the previous general testing covered the majority of Java and XML design, it
was important with the network (and subsequent XML) to ensure that all possible
combinations of road, junction and town organisation were used to allow for a full
analysis of the routing algorithm internal code.
Page 37 of 122
It was possible, using the code from the algorithms, to create a list of all possible
combinations of roads, junctions and towns used in the design and subsequently
update the network from Appendix R and cross-check this with the requirements of
the algorithms. The scenarios were then entered into a table during the white box
static analysis stage of testing, highlighting scenarios needed for the algorithms
alongside the matching situations existing on the network. Results of these
scenarios were then found during black box testing. Any errors found were
corrected by adapting the network appropriately.
Since static analysis occurred throughout the development of the project, this part
of the testing took place early, before the testing of the network and algorithms
themselves began. Once the algorithm was tested, the individual scenario was
deemed to be correct if a suitable route was created between the two suggested
nodes. Secondly, the test as a whole was deemed to be successful when all
possible aspects of the algorithm were explored.
15.6. Usability Testing
TekSci [13] defines Usability Testing as “testing the ease with which users can learn
and use a product”.
The theory of usability testing is to find out how users actually use a piece of
software. In a given test situation, users try to complete a series of tasks with an
observer following how that particular person does it. The idea, initially, was to
have at least three experienced and three novice users to gain a balanced opinion
on the system.
Tests assigned to a user needed to cover usability, their learning speed, time
required and their opinions on the software and User Interface (UI) in general.
Using usability testing benefited the UI design, allowing any flaws in functionality to
be identified and to give an idea of how a user would use a piece of software in the
real world. Principally, getting users to experience the software in a controlled
environment mitigates the risks of deploying untested software to a real community
of users.
This test plan was based on the work of Calgary University [14] and Shneiderman
[15].
Purpose
This test plan systematically tested user interaction with the system, and the
realistic use thereof. It encompassed full system functionality, raising any issues
with the system allowing them to be altered or fixed before final deployment.
Problem Statements
These were the important issues and questions that the testing of the system
needed to answer. They also helped decide the type of testing that would be
carried out.
Page 38 of 122
- Can the final user search for two locations with partial terms (such as a partial
name)? – system requirement 2
- Can the system accurately warn the user and allow the user to deal with such
messages, when traffic detected by other vehicles is about to be encountered? –
system requirements 3, 4
- Is the user distracted from the computer game (see ‘Testing Methodology’) they
are playing by the system while it is in driving mode? – system requirements 5,
6
- Does the user find the UI easy to understand? – system requirements 6, 9
- Can the system produce and display an understandable route, both in graphical
and written form? – system requirements 6, 9, 10
- Does the system notify the user in a timely manner when the destination has
been reached? – system requirements 5, 6, 9
How testing was conducted
The summative evaluation was a pre-test questionnaire (see Appendix S), followed
by a series of tasks that were based around each problem statement. These tasks
were then completed by each participant to see if all the problem statements had
been satisfied. After this there was a final concluding questionnaire.
Since developers tend to get attracted to their systems, remote or third party
observation of testing would have been ideal to ensure an objective, unbiased view.
In reality, time and cost constraints made this impossible; instead I supervised all
testing.
Participants
Initial beta testers:-
This was an expert group of three former and present Computer Science students
who, while unfamiliar with the system, were experienced with computers. Given
this, they were able to cast a critical eye over the system. It was reasonable to
assume that any problems experienced by these users would also be found by
more novice users, so any faults found here were considered and corrected if
appropriate before passing to a more general level of testing. Since these expert
users were also likely to be experienced with software design, through their
education at university, they would be able to give a good critique of the UI, which
allowed for changes to be made before final deployment to users.
Novice testers:-
Since the intended market for this project was courier firms or professional drivers,
it was possible to assume at least there would be a moderate level of ability with
navigation, maps and routes since these form a large part of their work. As such,
Page 39 of 122
novice users were in general (although not exclusively) experienced drivers and
moderate computer users; since the majority of teachers and lecturers fit this
description they will be used for this type of user. Additionally given the point and
touch nature of the user interface, the system should have been simple to
understand and easy to pick up with little instruction from me. There were eight
novice users in total.
Testing Methodology
The Traffic:Live! System is intended to be

an in-car system and as such driving is
expected to take place while receiving
directions from the system. To best
simulate the concentration requirements
of driving in real life, a distraction testing
method was implemented. A driving game
called Grand Theft Auto (figure 15.6.1),
was used once the details of the route
have been entered into the Traffic:Live!
system, with the simple requirement that
while driving in the game at some level of
speed the tester will not crash or hit the Figure 15.6.1 – Grand Theft Auto screenshot
virtual pedestrians while at the same time
understanding the spoken instructions given to them through the project system.
The tasks took each tester through a typical use of the system. For each section
during the pre-driving phase a series of questions were completed before testing
took place, based about the test problem statements - this gave useful feedback on
the system.
Once the system had switched into driving mode, the game playing began - after
this had started there were a few questions to assess the level of attention the
participant had been paying to the system.
Task List
The tests that each participant had to undertake can be found in Appendix S.
Evaluation
The testing finished with a post-task questionnaire (see Appendix S) to assess their
views on the software. In response to a user’s attempt at the tasks above, it was
possible to asses their effort in two ways.
Performance:- time to get through to the drive screen, errors made during
operation of the system and understanding of the spoken data – both compared to
the average of the expert users.
Preference:- ease of use, thoughts about UI
Page 40 of 122
These results were then compiled into various charts and spreadsheets and
analysed.
15.7. Results and Recommendations
During development the individual method and module white and black box testing
highlighted a number of issues, including methods that had a great deal of logical
complication. Errors found were corrected as they appeared leading to a final
working implementation. For all tests, associated data can be found in Appendix S.
15.7.1. System White Box Testing Results
Undertaking Fagan static analysis of the system during development proved

to be extremely beneficial for the project. In total, I held 21 sessions (by
myself) to review code for classes that exhibited complex code (that is, a
class where any logic or computation is undertaken). As a consequence of
the meeting a series of changes were made to each class.
Jtest, the code analysis tool was used to assess each individual class and
their individual methods for the correct actions. Because of the rigorous and
detailed analysis of the code at the Fagan testing stage, the errors found
were generally minor ones or coding guideline errors (such as lack of
Javadocs on some methods) – any significant errors are noted with the
testing results below for easy comparison. Where appropriate (for instance,
not those classes used from outside packages), these were corrected. Once
done, each class passed tests correctly.
While testing the networking XML files, minor errors were also found. These
were largely XML convention errors and were easily corrected.
15.7.2. System Black Box Testing Results
Each method was executed using the TrafficLiveTestHarness class or the

Jtest application after a standard network had been loaded and a route
between Lichfield and Exeter has been created where required (such as
History tests). Those with an ‘X’ next to them indicate a method that initially
gave errors against the expected valid test data set. These were
subsequently fixed and allowed the project to perform correctly. The actual
concept of boundary analysis was difficult to document because very few
methods actually received variable values. For each of the test cases in the
appendices it can be assumed that each class was corrected and responding
as expected by the time this project was deployed.
NB. Testing was not undertaken for classes where there was minimal/no
logic involved, such as the TrafficLiveBean. Where “Appropriate…” is listed
this indicates the output value should correspond with the result calculated
with an external mapping system such as Microsoft Autoroute for the values
selected by the tester.
Page 41 of 122
15.7.3. Route White and Black Box Testing Results
Since it was possible to plan the sample network (see Appendix R) in

advance, this meant that there was a significantly reduced chance of findings
error at this stage. Given this, no unexpected results were found during
testing.
15.7.4. Usability Testing Results
With time constraints it was not practical to implement the useful

recommendations derived from both expert and novice users during usability
testing. However, the majority of novice users (the expected end users of
the application) found the system easy to use, completed the tasks in a
reasonable amount of time compared to the expert users and intended on
utilizing it if it was made commercially available.
Task 1: Search for start and end location
• Text too small, probably a general problem for the whole

program.
• Search parameters are wide (they allow a wide range of
input for searching on, which could possible slow searching)
Recommendation: Text could be marginally increased, but space is

limited. Since only one user found a problem with this, text size will
be left for this release. With regards to the search parameters, since
the response is almost instant there is no need to change this
currently. Should the network significantly increase in size then this
could be changed.
Task 2: Calculate the route between locations and display directions
• No scroll bars.
Recommendation: Increase size of window to maximum allowed by

the PDA device, and consider implications if network is larger (and
directions are larger as a result). Implement scroll bar functionality if
required.
Task 3: Display the map for an intermediate location
• Difficulty using controls.

• Whole route cannot be displayed.
Recommendation: Make icons a little more obvious/larger and given

the rollover text describing what they do. Consider implementing
function to generate Scalable Vector Graphics (SVG) to display full
map.
Page 42 of 122
Task 4: Switch the system into drive mode
• Arrows not relative to vehicle.

• Drive mode may be misleading.
• Display of OS coordinates.
Recommendation: Calculations for arrow realignment could be done

and implemented if time allowed. Drive mode does the job of
describing what action it will perform, so this will be left. OS
coordinates would require a mapping method to convert latitude and
longitude appropriately – this could be added with time.
Task 5: Respond to warnings
• Responding by voice
• Controlling pop up time
Recommendation: Voice input is impractical for what at the moment is

a relatively cheap system to implement, this would add unnecessary
cost. Pop up time could be easily controlled given time.
Page 43 of 122
16. Critique
According to section 1.2, one of the main goals of this software was to provide an
alternative approach to in-car navigation, one that would effectively share information
with other drivers through a Peer-to-Peer network. Each primary goal in section 1.3 is met
by different modules within the final system. A driver, using this system would be able to
navigate between two locations avoiding any traffic disseminated through the warning
system. The project also goes some way to answering the first of the secondary goals, by
providing a limited web interface to the Message Centre.
As the project progressed it became obvious that the project would extend the
functionality of the system well beyond these original ideas, as demonstrated by the more
detailed system requirements in section 7. For instance, each vehicle is now able to detect
other traffic and obtain dynamic maps from online mapping companies, both of which
were not originally planned. While initially it was expected that there would have been
some further development beyond the scope of this project to enable it to be used in a
real vehicle, this is in fact not the case and the system is now ready to deploy in its
current state.
The backend section of development for the vehicle system proved to be the most
challenging part and presented a great deal of work that had not been considered during
the design stage, such as providing threading in the Message Centre to generate cached
data to reduce load on the server. There were also a number of shortcuts in the form of
external APIs that provided functionality, such as access to a GPS device. Such
shortcomings in design are relatively common in my own experience and in past projects
that have been used as research, and are accounted for in RAID (Risk, Assumptions,
Issues and Dependencies) planning.
The development of the backend implementation of the system also exceeds its design
stage. There was a large amount of unexpected development such as implementing a
servlet for the Message Centre and playlist module, instead of the JSP/Java Bean solution
used throughout the rest of the project. This gave me a lot of extra work, but also allowed
me to develop my skill set. Some parts were also quite easy: the facility to provide audio
feedback for on-screen messages proved to be relatively simple to develop and were
actually quite effective and flexible, particularly in terms of number output.
The frontend implementation meets its requirements very closely. The actual deployment
version is exactly the same on the surface to the mock pages produced at the design
stage. It remains a simple system and is uncluttered. During usability testing, users
commented on how easy the system was to learn and the majority planned on using the
system if it were to become commercially available.
One of the main areas of interest in the development was the Peer-to-Peer section – this
sets the software completely apart from all other existing solutions. The implementation
was complex but proved to be successful. The vehicle is able, at the users’ request, to
divert around traffic and establish effective alternative routes informing the user as it
goes.
Users generally found the system helpful and well designed to complete their tasks, a
clear sign that the software was successful. The software is not perfect, but then no
Page 44 of 122
software is perfect. If I were to have more time or to develop it again I would probably
spend some time working on the front end to make the use of it on a small-screen PDA
more realistic (such as larger fonts and voice input). In terms of the backend, I would
enhance the Message Centre to be more scalable and handle thousands of vehicles active
on the road network.
The system has many possibilities for future enhancements and development. One idea
suggested during usability testing was the addition of a link to established traffic
information providers (such as the RAC or AA) to provide a more detailed level of
information to drivers relying on the Traffic:Live! system. It would also be possible to
broaden the range of devices the application could run on, perhaps allowing to be used
from a mobile phone, where users could then have access to the same system
functionality without an installed device. This further development would require a
different approach to implementation since the majority of hardware in the current system
is intended to be deployed within the user’s vehicle, but nonetheless this idea is entirely
possible.
I have learnt a great deal during the development of this project. My skills have been
particularly enhanced in the fields of information sharing, scalability and enterprise level
Java. The Traffic:Live! application has turned into a relatively large scale deployment and
has increased my ability to manage large amounts of diverse work over an extended
period of time.
Page 45 of 122
17. Bibliography
• Eugen Leitl, ‘Wifi Highway - could this work?’,

http://www.xent.com/pipermail/fork/2003-January/016306.html, 3rd January 2003
(accessed 26th October 2003)
• John Moy et al., ‘Open Shortest Path First IGP (ospf)’,

http://www.ietf.org/html.charters/ospf-charter.html, 16th September 2003
• MobileGPRS.com, ‘All about General Packet Radio Service (GPRS)’,

http://www.mobilegprs.com/gprs.asp?link=1, Unknown (accessed 27th October
2003)
• Google.com, ‘Google Directory, GPS – Global Positioning System’,

http://directory.google.com/Top/Science/Earth_Sciences/Geomatics/GPS_-
_Global_Positioning_System/?tc=1, 27th October 2003 (accessed 27th October
2003)
• Wireless Developer Network, ‘WML Tutorial’,

http://www.wirelessdevnet.com/channels/wap/training/wml.html, Unknown
• Google.com, ‘Google Search, Wireless Networking’,

http://www.google.co.uk/search?hl=en&ie=UTF-8&oe=UTF-
8&q=wireless+networking&meta=, 27th October 2003 (accessed 27th October
2003)
• The AA, ‘The AA: Route Planner’,

http://www.theaa.com/travelwatch/planner_main.jsp, Unknown (accessed 27th
October 2003)
• Various, Proceedings of the Vehicle Navigation and Information Systems

Conference, IEEE, Various.
• R. Flickenger, Building Wireless Community Networks, O’Reilly, 2002.
• Geotools, ‘GeoTools :: News Articles’,

http://www.geotools.org/index.php?module=articles&func=view, 19th January 2004
(accessed 19th January 2004)
Page 46 of 122
18. References
[1] Roozbeh Razavi, ‘Howstuffworks “How Routing Algorithms Work”’,

http://computer.howstuffworks.com/routing-algorithm.htm/printable, Unknown
(accessed 10th November 2003)
[2] Simon Meaden, Project III, Department of Computer Science – University of

Exeter, 2003
[3] Patrick Henry Winston, Artificial Intelligence Volume 3 Chapter 5 – Nets and
Optimal Search, Addison-Weasley, 1992.
[4] Shashi Shekhar et. Al., Chapter – A comparison of hieracrchical algorithms for
shortest path computation, University of Minnesota, 1996.
[5] Open GIS Consortium Inc. (Simon Cox, Paul Daisey, Ron Lake, Clemens Portele,
Arliss Whiteside), ‘Geography Markup Language (GML3.0)’,
http://www.opengis.org/docs/02-023r4.pdf, 29th January 2003 (accessed 10th
November 2003)
[6] GeoTools.org, ‘GeoTools Introduction’, http://www.geotools.org, 2003 (accessed

12th November 2003)
[7] Peter H. Dana, ‘The Global Positioning System’,

http://www.colorado.edu/geography/gcraft/notes/gps/gps_f.html, 1999 (accessed
2nd November 2003)
[8] John B. Wordsworth, ‘Information Systems Development’,

http://www.dcs.ex.ac.uk/~jbwordsw/InfoSysDes/J2ISDUUC.pdf, October 2002
[9] Agile Modelling, ‘UML 2 State Machine Diagram’,

http://www.agilemodeling.com/artifacts/stateMachineDiagram.htm, 8th August
2003 (accessed 23rd January 2004)
[10] ZIPCodeWorld, ‘Distance Java Code’,

http://www.zipcodeworld.com/samples/distance.java.txt, Unknown (accessed 19th
January 2004)
[11] Michael Fagan Associates, ‘Michael Fagan Associates’, http://www.mfagan.com,

Unknown (accessed 23rd January 2004)
[12] gotdotnet, `XSD Schema Validator’,

http://apps.gotdotnet.com/xmltools/xsdvalidator/, Unknown (accessed 22nd
January 2004)
[13] TekSci, ‘Dictionary’, http://www.teksci.com/teksci/dictiona.asp?start=u, Unknown

Page 47 of 122
[14] University of Calgary, ‘Usability Testing – Developing a Test Plan’,

http://pages.cpsc.ucalgary.ca/~saul/681/1997/jas/plan.html, 1997 (accessed 17th
January 2004)
[15] Ben Shneiderman, Designing the User Interface (3rd Ed.), Addison Wesley, 1998
[16] James Hobart, ‘Principles of good GUI design’,

http://axp16.iie.org.mx/Monitor/v01n03/ar_ihc2.htm, 1995 (accessed 12th
November 2003)
[17] Philip R. Cohen and Sharon L. Oviatt, The Role of Voice Input for Human-Machine
Communication, Oregon Graduate Institute of Science and Technology, Unknown
[18] Justin Heyes-Jones, ‘A* Tutorial’,

http://www.geocities.com/SiliconValley/Lakes/4929/astar.html, 2001 (accessed
17th January 2004)
[19] W3 Schools, ‘XSD How To’,

http://www.w3schools.com/schema/schema_howto.asp, Unknown (accessed 20th
January 2004)
Page 48 of 122
Appendix A – Software Reviews
A.1. Microsoft Autoroute 2002
Microsoft Autoroute has been available

for many years (it was previously owned
by another company) and so as a result
is extremely detailed, and with yearly
releases is fairly up to date.
The interface is relatively simple,

consisting of a map, directions and data
searching, the map being easily
manipulated with a mouse or keyboard.
Autoroute has some useful features
such as street level and postcode route
finding so, given a pair of postcodes, a
door to door map could be produced.
Figure A.1.1 - Autoroute interface
When used in-car, the system was able
to provide some basic functionality including GPS navigation and step-by-step instructions.
However, this does have some drawbacks with no easy to understand feedback for the
driver such as large text or speech; neither does the software update very frequently
when connected to a GPS making it very easy to miss junctions and turns while travelling.
I believe the application would be more suited to use by a passenger.
Good points:
• Extremely detailed maps.

• Fast and efficient route finding.
• Facility for using a GPS device (albeit with a rather limited update
frequency).
• Does not require the CD or a connection to the Internet.
Bad points:
• Route details can sometimes be complex to the point of driver distraction.

• No audio or speech feedback facilities.
• GPS function seems to be displaced (ie. incorrect by around 300 or 400
metres, as a result of software rather than GPS error).
Project points:
• Autoroute’s professional “big brother”, called MapPoint, has an API and so

enables customised applications to interact with it and obtain routes.
• The Autoroute implementation of GPS is simple to use and could be used
well in the project.
Page 49 of 122
A.2. ViaMichelin
ViaMichelin (formerly Shell Geostar) (http://www.viamichelin.com) is a European based

travel and route finding information web site. As with other web route finding tools the
interface is simple and quick to use. Since it is web based it is more likely to be up to date.
Unfortunately it does have a few significant

drawbacks. First, a map is not displayed by
default – the user has to specifically choose
to see it, which is time consuming. Second
and crucially, the long distance route finding
of the system seems to take significantly
different and misleading routes compared to
the other systems. In the example, the
suggested route takes the driver over to a
distant motorway before heading south.
Additionally, rather unhelpfully, the system
chose to dispense with the destination
postcode, instead deciding to navigate to the
rather ambiguous destination motorway
junctions before abandoning the driver
without giving directions to Exeter itself.
However, the system did seem quite

competent at short distance journeys
providing simple and direct routes across Figure A.2.1 - ViaMichelin interface
Exeter.
Good points:
• Clear and simple to use.

• Accurate over short distances, this could prove useful for cross-city
navigators.
Bad points:
• Misleading, poor directions over long distances.

• Limited functionality besides basic route finding.
Project points:
• Turn by turn arrows on short distance directions are simple since they given
an “at a glance” view of a route ahead.
Page 50 of 122
A.3. The AA
The website (http://www.theaa.com/travelwatch/planner_main.jsp) can be accessed from

anywhere in the world and could theoretically be reached through a mobile phone with
GPRS or a laptop with WiFi. Since it is online it can also be updated dynamically by the AA
and so would be right up to date.
When the results were displayed they used practical points of reference such as:
1.2 A461 Muckley Corner ("The Olde Corner House Hotel")
At roundabout take 2nd exit
The system seems ideal for reading by a driver before a journey since the general
directions are easy to follow. The website is fast, and requires no special plug-ins to be
installed. However, besides route navigation the system has no further functionality, and
particularly cannot use a GPS device.
Good points:
• Fast and free.

• Online based, so up to date.
• More flexible points of reference
for a driver to memorise.
Bad points:
• Inaccurate postcodes (limited to

the first part and first letter of the
second), and limited street level
mapping.
• Requires an Internet connection.
• No facility to plug in a GPS
device.
• Limited map manipulation. Figure A.3.1 - AA interface
Project points:
• Turn information is very good since it uses local landmarks, such as pubs, to
provide user with simple directions.
Page 51 of 122
A.4. The RAC
The RAC route planner (http://rp.rac.co.uk) seems to be trying to target a number of

different users since it includes the facility to switch between vastly varying levels of
detail. It also functions to create printer friendly, emailed (although this did not work) or
voice (mobile phone) versions, which could prove very handy when being used by one
person directing another.
There are a large variety of route planning facilities within the website, allowing a user to
not only navigate by town and
postcode, but also but also by station
or airport, with additional destinations
on route. This could be used when
returning from the airport to your
home address – a fairly unique
feature.
However, unfortunately the RAC’s

intent has also caused fairly important
problems; first it uses Java to display
maps which makes the whole
experience very sluggish. Second
some of the key features of the site,
such as being able to receive a link to
a route by email do not work.
Good points:
• Detailed routes with

navigation hints in the
form of arrows and start
and finish points.
• Facility to switch Figure A.4.1 - RAC interface
between short and
detailed descriptions
• Extremely user friendly step-by-step map (on a par with an old AA strip
map).
Bad points:
• Very slow, partly caused by the map which uses Java - this causes a
significant slow down each time a search is done.
• Some functions of the website failed to work.
• It assumes a fixed average speed of only 60mph on the motorway which
given good conditions is rather conservative.
Project points:
• Displays simple turn and road symbols for a brief overview of the route.
• Facility to switch between different types of information.
Page 52 of 122
A.5. Tom Tom for the PocketPC
The PocketPC is effectively just a tiny portable computer which, with appropriate software,
enables route planning and navigation just like a full size version. However the benefits
come from the size and portability. Tom Tom is a piece of software for the PocketPC that
enables a viable form of in-car navigation when hooked up with a GPS device.
Maps within Tom Tom are taken from a more 3D

perspective than traditional route planning systems
enabling the user to look ahead and see turns that
are coming up. The maps are simple, but since the
software is designed for in-car use this really is not
an issue.
An interesting point to note here is that the system

has a feature called ‘road blocking’, allowing
instant re-planning around any unexpected
obstacles found during the course of a journey –
this is an example of something that will be
implemented in this project.
Tom Tom also has extensive databases of nearby

attractions such as fuel-filling stations, pubs and
places to sight-see - although how practical this Figure A.5.1 - Sample Tom Tom interface
would be to use with a point-and-type approach of
many palmtops remains to be seen.
It was not possible to get test route information since a sample was not available at the
time of writing.
Good points:
• Portable.
• Simple, easy to use maps, ideal for a driver.
• Allows use of a GPS device.
• Can navigate around traffic, albeit not automatically.
Bad points:
• Expensive.
• Could be distracting as it has limited voice feedback and input.
• Small screen could be difficult to use by some users (for instance, those with
eye sight correction).
Project points:
• Excellent map display that makes it very easy to visualise coming turns.
• Has the facility to navigate around road blockages in a simple manner (point
and click when an event occurs).
Page 53 of 122
Appendix B – Routing Algorithms
Search algorithms allow the system calculate, through a variety of methods, the route
between two locations.
B.1. Link State algorithms (LS)
This algorithm first builds a graph of the network, then using this, the algorithm identifies
the initial node as V1 (where the vehicle currently is)
and the destination node as V2 (where you are driving
to). The second step is to permanently mark the
current node as a T-node (a Traversed node). Using a
vehicle’s network map the algorithm then works out the
adjacent nodes to that of V1 and selects the one with
least cost – this then becomes the new current node.
At this point the node can be in one of the following

states:
1. a dead end
2. not the destination
3. the destination
If it appears that the node is state 1, then the

algorithm backs out and tries a different route, marking
off the first attempt as invalid. Given state 2, the
algorithm proceeds from this point as before, following
the path of least cost until eventually, the T-node is the
final destination (V2). The final route is identified by
stepping back through the route to produce a string of
valid T-nodes.
Figure B.1 – LS algorithm flow chart
Although this algorithm works well, it does get
complicated, particularly with a large network. Additionally, given an error in the network
map routing decisions could prove entirely wrong (however, we are assuming this will not
happen). However, since it is created on a route by route basis, it could quickly
accommodate traffic problems identified at any particular node: a definite plus for this
project.
B.2. Distance Vector algorithm (DV)
DV algorithms are significantly different in that each node on the network knows to which
of its adjacent nodes to route traffic, in order to reach any other node on the network.
Each node has a it’s own local table to refer to. For example a network graph and routing
table for node J might appear as the following, where each letter represents a different
destination in the system:
Page 54 of 122
Destination Weight Line

A 8 A
B 20 A
C 28 I
D 20 H
E 17 I
F 30 I
G 18 H
H 12 H
I 10 I
J 0 ---
K 6 K
L 15 K
Figure B.2 – DV routing table
In this example, for the most efficient route from J to C, a vehicle would first travel to I
(following details from the ‘Line’ column from the table). Once the vehicle has reached
node I, it would then refer to the table for that node and see that the node to travel to
would be E, and so on. The vehicle would eventually reach C after three traversals.
This algorithm has one primary benefit – it is very fast, but it does rely on data being
known about every node, by every node; when a new node is added to the network it
could take time for the routing table to update. This algorithm is similar to how many
Local Area Networks route their traffic.
In the case of this project, where a ‘link’ or road can become unavailable due to heavy
traffic or local conditions, a vehicle would need another system to be able to repopulate
the routing table taking into account the missing link. This could be achieved by iterating
through the map, where each node would have to take the following steps:
1. Calculate the weight of the links directly connected to it, adding this to its
own routing table.
2. Share the routing table with the neighbouring nodes that then add this
new information to their table and return a table to the originator
containing the same new information, which then does the same.
This would take a little bit of time, but should not prevent dynamic route calculation from
taking place. However, the algorithm does, as a result, have a drawback. When a node
has only a single link to another node, the algorithm can have time consuming issues
Page 55 of 122
when this link is cut. Because of this distributed nature of the information there is no
central source that says that the link has been cut and the nodes continually swap
information until they realise that no node has a working link with the disconnected node.
The process loops over again until the cost of the connection reaches infinity (it is
unreachable).
This issue can be solved by adding a condition to each node that it is not to share
information with what it knows is the exclusive link to the disconnected node, thus
preventing information cycling around. Either way, this can only add to the data load of
this algorithm.
Both of the above algorithms need each node to know information about other nodes;
with a growing network this can become increasingly inefficient. An alternative to this is to
use hierarchical routing.
B.3. Hierarchical Routing algorithm (HR)
HR has some key areas that relate

well to real world modelling. Groups of
nodes are classified into areas known
as regions (which could relate to
regions of a country for example). For
example, in region 1, each node then
only knows about nodes local to it
(using DV algorithms) and knows
nothing about other regions except
that one of the local nodes connects
with say, region 2. This simplifies the
data that each node has to hold and
makes updating routes simpler.
Figure B.3 is an example of a two-tier

hierarchical routing table – it can be
made to be a three or four level
hierarchy involving clusters, which Destination Line Weight
are a subset of regions. The table A --- ---
shows routing information for the A B B 1
node. This could be used well within
C C 1
the project since the idea is to have
Region 2 B 2
separate areas of local mapping, with
Region 3 C 2
inter-connecting motorways linking
them. The HR method of routing is
Region 4 C 3
widely used across Wide Area Region 5 C 4
Networks, such as the Internet. Figure B.3 – HR routing table and map
Page 56 of 122
Appendix C – Communications Technologies
WiFi is a relatively high bandwidth (theoretically around 54Mbps) form of networking that
natively supports direct TCP/IP between hosts, which would enable the rapid deployment
of peer-to-peer applications. However it has a rather fundamental drawback that clashes
with this project in that it has a short range of transmission, usually no more than 300
metres or so. Given the intended use of the technology, knowing only what traffic there is
up to 300 metres away from you would negate the worth of this concept.
GPRS is a similar packet switching technology to that of WiFi, albeit rather slower with a
maximum bandwidth of 115.2Kbps. Connections are made as bursts of data using the
spare capacity of GSM networks, and are commonly used for mobile internet browsing and
email download. The range of such a device is only limited by whether or not a mobile
signal is obtainable – coverage is nearing 100%, particularly around busy roads and
motorways making this seem ideal for the project.
The main issue with this form of technology though is not the speed or coverage but the
type of connection provided. When a mobile phone connects to this system it is allocated
an IP address by the mobile operator, however this is a private one of the form
172.16.xxx.xxx. This is un-routable from the Internet or other clients, and subsequently
peer-to-peer communication would be impossible. However, using an intermediary such as
a simple messenger service, messages could be passed from client to client making an
effective peer system.
3G and GSM dial-up are both similar to GPRS in that they give a private IP and
connection to the Internet. 3G, a packet switched service, can operate up to a theoretical
2Mbps (very fast) and GSM dial-up, a circuit switched service, up to 9.6Kbps (very slow).
3G is a relatively new service that has so far, at least in the UK, only been introduced by
one carrier called “Three”. The uptake of the service has been limited and data facilities
and coverage are very limited at the time of writing – this makes the use of 3G impractical
for the purposes of this project. GSM dial-up by comparison is an old service, but since it
is circuit based (meaning it relies on a continuous signal to remain connected) it will be
impractical for the sporadic messages of this project.
FM and CB radio are not normally related directly to computer traffic, but since FM can
be used for sending basic digital data through the RDS (Radio Data System) it is worth
covering it in this review. The basic idea is that each FM radio station is given a set
bandwidth that it can use for its broadcasting, however, since most stations do not use all
of their bandwidth the spare could instead be used for transmitting very low bit rate data.
The RDS signal is modulated into the radio station signal and transmitted in parallel. This
could theoretically be used for one way message passing to a car, but this would rely on a
central station with knowledge of most traffic situations, going away from the main of the
project. Furthermore, since broadcasting without an expensive license is illegal, at least on
the FM band, it makes its use in this project impossible. While CB radio would avoid the
issue of licensing, the system is receiving increasingly less use and as a result hardware is
difficult to obtain.
Page 57 of 122
Appendix D – User Interface
D.1. Textual Input and Output
Textual input can be done in two ways - through an actual keyboard (be it a full size or a
PDA attached one) or a virtual on-screen keyboard. The first has the drawback that a
keyboard of some kind would be physically required in the car (although this could be
small), and the second could be rather difficult and slow to use accurately depending on
the key spacing and could frustrate the user.
Project points: This needs to be restricted to use only when the car is not in motion, since
typing (or using a touch-screen virtual keyboard) is very distracting to the driver. Text
could be used when specifying destination and other parameters. In Java this is one of the
most basic things about the language and should not pose any problems during
development.
Textual output would be displayed on screen and can be any size or font within reason
making it flexible.
Project points: A project aim is to display basic route information for the driver, so at a
glance they can establish approaching turn information. Since this application is being
developed to be suitable for use on a PDA screen, space will be limited. As with input, the
text needs to be restricted since it can be distracting to a driver. The text used on the
Tom Tom application is a good example of this use, since it displays speed and turn
information clearly.
D.2. Graphical Input and Output
Graphical input sits somewhere in the middle

between voice and textual input, but good design
is the key aspiration of a developer [16]. A
Graphical User Interface (GUI) is the most
common way for people to interact with a
computer, and by that fact, probably the form
they are most comfortable with. As with every
other form of human interaction a GUI has some
drawbacks; primarily that the user has to divert
some attention from the road to look at things to
click or select. Of course, it would be possible for
some graphical interaction to take place before
driving commences, such as selecting where to
begin and end a journey.
Figure D.2.1 – Example of map from MultiMap.com

Project points: The use of a GUI is familiar to
almost every user and allows simple interaction between user and system. However, it
could be dangerous to user if intended for use while driving. It will most likely to form part
of the application but not to be the primary interface for use in motion.
Page 58 of 122
Graphical output also forms part of the GUI, concentrating on passing data back to the
user. In the project this could be used for reporting the current location of the vehicle or
showing TBT information. Using an online mapping server such as MultiMap.com it would
be possible to obtain maps specific to the route in a vehicle system for use on-screen.
Project points: GUIs are obviously useful since they enable a short learning curve for new
users. The project will use them in the initial part of the interface but limit them once the
user is in motion, involving an odometer to monitor car motion, switching between
graphical and voice mode automatically.
D.3. Voice Input and Output
One of the main uses for a voice input system is for [17] “when the user’s hands or eyes
are busy“. This is probably the most complex part of a user interface; every person has a
different voice and so inherently, for a computer, has to be understood differently.
Speech-recognition technology is built into Windows XP (the probable platform for the
project) but is rarely used on conventional systems. The recognition by the computer is a
two-way process; you train the computer to understand your speech and at the same time
you learn to adapt to a form of clear speech that the computer will take to more easily.
Project points: Given time, the speech recognition system could work with an in-car
navigation system and would be relatively easy to add to the system, but two drawbacks
might prevent the idea taking off. First, users are unlikely to have the patience to sit in
their car for an hour or two ‘training’ their computer to understand them. Second, with the
ambient noise of driving, the user is likely to become frustrated by the computer that
would have a great deal of trouble understanding them.
Voice output is a different situation entirely. There are two solutions, both of which would
be possible to implement:
- speech synthesis, using for example Microsoft Speech

- pre-recorded speech
Microsoft supplies a Software Development Kit (SDK) that enables the user to add speech
functionality to their development software, and in particular the text-to-speech engine
(using the Microsoft Sam voice) is free to distribute. This approach has some benefits:
- Easy to produce dynamic text on-the-fly

- Free, and relatively easy to implement
However, the main problem with the system is that the voice could prove difficult to
understand, again when played against the background noise of the car. The system could
be linked to the car radio to enable the in-car speakers to be used which could alleviate
this.
The alternative is for someone to record into wave files everything that the system would
ever need to ‘say’. Once each word is recorded, the system could provide on the fly
compilation of words to create complete sentences. This would have the main benefit of
being easy to understand by the user, however, it would be:
Page 59 of 122
- Time consuming to produce each word

- Difficult to write a database that holds the words correctly, to allow them to be
built into sentences
Project points: Given that part of the project is to look at the interface design, a hybrid of
the two output systems would be most suitable here. For the regular and re-occurring
data pre-recorded speech would be used to give the interface a quality feel, and then on-
the-fly generation would be used for everything else, such as directions.
Page 60 of 122
Appendix E – Storyboard
Page 61 of 122
Appendix F - System Architecture Communication Links
NB. Where relevant, a number in parentheses represents the related entry from the earlier system
requirements of section 7.
1. The user commands are sent to the corresponding Java Bean interface on the BE. (4) (6)
(9) (10)
2. Data is passed back to the front end for display as part of the JSP page. (4) (6) (9) (10)
3. The Vehicle System issues commands and data to the Java Bean for display on the FE. (4)
(6) (9) (10)
4. The Java Bean passes data back from the FE to the main BE system. (4) (6) (9) (10)
5. Periodic data about the condition of the car (such as speed and location) is passed to the
Messaging Sub-system. (3) (4)
6. The Messaging Sub-system updates the live database with local and remote condition
information. (3) (4)
7. Periodic data about the location of the vehicle is passed to the GPS Logging Process to
store the location over time. (7)
8. The GPS Logging Process formats the location information and saves it to the data store.
(7)
9. The Vehicle System passes details of the required route to the Routing Sub-system. (2) (4)
(5) (9) (10)
10. The Routing Sub-system passes details of the journey, such as directions to the Vehicle
System. (2) (4) (5) (9) (10)
11. The Routing Sub-system uses the Route Finding Algorithms to calculate the journey. (2)
(4) (9) (10)
12. The Route Finding Algorithms return their results to the Routing Sub-system. (2) (4) (9)
(10)
13. The Route Finding Algorithms process the GML Network and Geometry for the best route
between the required nodes. (2) (4) (9) (10)
14. The GML Network and Geometry data, via the GeoTools Middleware, is passed to the
Route Finding Algorithms as required. (2) (4) (9) (10)
15. GeoTools Middleware uses the databases, through an interface defined in XSD (XML
Schema Definition). (1) (2) (4) (9) (10)
16. The results of data queries are passed through the GeoTools Middleware in a uniform
manner. (1) (2) (4) (9) (10)
17. The connection to the GML Network. (1) (2) (4) (9) (10)
18. The connection to the GML Geometry, metadata to the GML Network (static). (1) (2) (4)
(9) (10)
19. Further GML Geometry, containing live updates from the Messaging Sub-system. (1) (2)
(4) (9) (10)
20. The Messaging Sub-system passes local data to the Message Centre for use by other
vehicles. (3) (8)
21. The Message Centre passes data from other vehicles for use locally. (3) (8)
22. The Messaging Sub-system warns the Vehicle System that it has received useful messages
from the Message Centre. (3) (4)
23. The Routing Sub-system validates the start and end location. (2) (4) (9) (10)
24. The Vehicle Simulation system warns a vehicle is in vicinity and provides GPS location data
to the system. (3)
25. The Vehicle System passes its location for broadcast via the Vehicle Simulation system.
(3)
26. In lieu of a real GPS receiver, the Vehicle System obtains its [GPS] location from the GML
network via the GeoTools Middleware. (1) (7)
Page 62 of 122
Appendix G – Use Cases
Traffic:Live!
Create new route

(2)
Avoid problem (4)
Search route (1)

(2)
User Get directions (2)
(5) (6) (9)
Drive (2) (3)

Get map (2) (5)
(6) (9) (10)
Download relevant
remote messages (3) (4) (8)
Transmit local
Message Centre
Time messages (3) (8)
Transmit location
(3) (8)
Log GPS data (7)
Log road
conditions (1) (3)
Numbers in brackets refers to the related system requirement from section 7 of the earlier
research.
Page 63 of 122
Appendix H – Activity Diagrams
Activity Diagram –
Create New Route User System
no current route:
display prompt
enter details, press key
{}
report error
quit
create route object
no change:
cancel or quit
route added:
Page 64 of 122
Search Route User System
route entered:
validate route object
return to previous screen report error
search key or quit
{}
create results object
display results
results added:
Page 65 of 122
Avoid Problem User System
message received:
create warning object
report problem
avoid key or ignore key
{}
create new route object
validate route object
create results object
display results
results added:
Page 66 of 122
Get Directions User System
route searched:
access results object
display results
{}
results displayed:
Page 67 of 122
Get Map User System
route searched:
access results object
generate map object
display map
{}
map displayed:
Page 68 of 122
System Message Hub

Download
Relevant Remote
Messages
Time
poll time
initiate data request
generate message object with location
{}
{}
request data
error
store data
failed:
data downloaded:
Page 69 of 122
Activity Diagram – System Message Hub

Transmit Local
Messages
Road Conditions
Logger
poll traffic logger
initiate data transfer
generate message object
{} {}
transmit data
error
failed:
data transmitted:
Page 70 of 122
System <<system>>
GPS Logger
Log GPS Data
Time
poll time
initiate data store
obtain location and generate GPS string
{} {}
store data
error
failed:
data stored:
Page 71 of 122
Transmit Location
System Other vehicles
get vehicle location
generate message object
transmit data
{}
error
failed:
data transmitted:
Page 72 of 122
Activity Diagram – System <<system>>

Log Road Road
Conditions Conditions
Logger
Time
poll time
initiate data store
obtain location and speed and generate conditions object
{}
store data
{}
error
failed:
data stored:
Page 73 of 122
Appendix I – State Charts
State Chart - State Chart –

Vehicle Routing
restart
ignition stopping
new route
restart
stopped
restart empty
restart
acceleration
user entering
data restart
driving locations entered

restart
changing restart
matching
speed
data
searching
around
area
locations matched
ignition
ignition searching
results found
generate
generate generate
directions displayed map displayed
generate
navigate
warning
received
navigating warning displayed
ignore
finished
Page 74 of 122
State Chart – State Chart –

Message Centre Messaging in
Vehicle
startup startup
incoming time to
connection time to check poll geometry
idle idle
for messages
message received checked for remote messages geometry status read
done
done receiving formatting
messages message
done
messages received
relevant messages transmitted store message message prepared
add to
done
incoming geometry
connecting to
connection message centre
network status updated transmitted
State Chart –
GPS Logging
startup
done
idle sentence stored
time to store storing

location data sentence
vehicle location read sentence prepared

generating
sentence
Page 75 of 122
Appendix J – Classes and Relationships
Warning
Edge
-newAvSpeed : int 0..* has many 1
-timeAtFix -name : string
-locationAtFix : Location -startNodeId : int
-ownerOriginated : bool -endNodeId : int
-startEndDir : bool
Node -endStartDir : bool
-normalSpeed : double
-location : GPSInfo
-length : double
1 -nodeName : string 2 consists of 0..*
-nodeClass : char 1
-subnet : int
0..*
0..1 0..2
edge order is
EdgeResultOrder
has many
represented by
-position : int
has a pair of
is in a
0..1
has intermediate
1
1
GPSInf
Route Result
-sentenceId : string is created from
-startName : string
-utcTime
-startNodeId : int 1
-latitude : double 0..1
-endName : string
-nsIndicator : char
1 -endNodeId : int
-weIndicator : char
-validated : bool
-longitude : double
-positionFix : int stores
-satellitesUsed : int
-hdop : float
0..*
-altitude : float
-altitudeUnits : char 1
-geoidSeperation : float
-seperationUnits : char location over time Vehicle
-dgpsAge : float
-dgpsStationId : int = 0000 -ownerName : string
0..* -currentLocation : GPSInfo
-checksum : string = *75 0..1
-terminator : string = CR/LF -currentSpeed : int
-speedThreshold : int
-localTraffic : bool
0..*
Class Diagram -
Vehicle
Page 76 of 122
Class Diagram -
Message Centre
VehicleWarning
-vehicleId : int
-edgeID : int
-roadName : string is as
socia
-startEndDirection : bool
1..*
te d wit
-newSpeed : double h
-date : Date
Location
-sentenceId : string
-utcTime : float
-latitude : double
-nsIndicator : char
-weIndicator : char
-longitude : double
-positionFix : int
-satellitesUsed : int
-hdop : float
-altitude : float
-altitudeUnits : char
-geoidSeperation : float
-seperationUnits : char
-dgpsAge : float
-dgpsStationId : int = 0000
-checksum : string = *75
-terminator : string = CR/LF
Page 77 of 122
Appendix K – Front End Design
Note: It is important to note here that the grey bar (Preview:…) at the top of each mock
screen is only there for the purposes of fast access to each screen during the design stage
and will not be visible in the final version.
K.1. Initial Location Search Screen
Figure K.1.1 – Initial Location Search screen
This screen is the first that a user would see after a potential splash screen. As is common
with other web forms there are two main text fields and a drop down, with Calculate (like
the Submit button) and Clear buttons. The intention here is for the user to enter where
they would like to start and end their journey. The system will be able to handle partial
matching, so for instance ‘Lich’ would match to ‘Lichfield’.
The small light green button to the right of the From field allows the user to quickly select
their current/nearest location (either a town or road junction) and automatically enter it
into field. Since the vehicle is always aware of its own location, this will be an extremely
quick function to execute. Finally, the ‘Speed Threshold’ drop-down is there to allow the
user to change the point at which messages received from other vehicles are acted upon;
the higher the value, the more warning messages will be displayed.
Page 78 of 122
K.2. Location Confirmation Screen
Figure K.2.1 – Location Confirmation screen
Once a user has advanced to the next screen after entering their start and end
destinations they are presented with the opportunity to confirm what the system thinks
they meant when then typed something like ‘Bir’ instead of ‘Birmingham’. The idea here is
that if the system has guessed incorrectly, they can cancel and search again. Should there
be many matches; the fields will be replaced by a drop down selection box of possible
matches of location name, for further selection at this stage.
However, assuming the chosen locations are correct the green button can be pressed to
advance to the next screen.
Page 79 of 122
K.3. Map Screen
Figure K.3.1 – Map screen
At this point, the route has been calculated, and the system now displays a map showing
the start and end locations along with a highlighted line showing the route between the
two locations. The map shown in this picture is an extract from Microsoft Autoroute 2003
and does not represent what the final map will look like.
This screen allows the driver to get an idea for the general direction in which he or she
will be travelling. There is no facility to zoom or move the map since it has been
specifically rendered just to show an overview map.
The user now has a choice between viewing the directions for the displayed journey and
switching into driving mode. The difficulty of keeping the major buttons in green and red
is highlighted here since both buttons in this case have a positive action. During user
testing it is possible that a decision may be made to keep them both green.
Page 80 of 122
K.4. Directions Screen
Figure K.4.1 – Directions screen
This screen shows the driving directions between the start and end locations. It is
generated by working backwards through the nodes after the routing algorithms have run.
When the directions for a journey grow too long, scroll bars will appear on the right hand
side to allow the user to scroll up and down through the list; since the driver will be
stationary at this point this should not pose a safety risk.
Again, as with the other screens, there is a pair of green and red buttons at the bottom of
the screen. Since the user must have come from the previous screen, the map, this button
is in red since it is a ‘negative’ action (that is, going backwards) and the green drive
button is ‘positive’.
Page 81 of 122
K.5. Driving Screen
Figure K.5.1 – Driving screen
This shows the main driving screen for the Traffic:Live! system – the intention is that it
will be displayed continuously while the vehicle is in motion, as such the green and red
buttons at the bottom of the screen will not function at this time (to comply with the UK
laws highlighted in section 5 of earlier research). The top portion, below the system logo,
shows the direction of travel in word and with an image, and the distance to be travelled
is also shown.
This information will update every few seconds throughout the journey, as well as this
when there is a significant change the system will play a voice output of the information
contained on the screen. A significant change will be either a change in location, or a
change in require direction.
To give the driver a sense of location and the feeling of progressing along a route their
nearest current location is shown and spoken, in terms of the network for this project this
might be one of the following:
- road (e.g. M5S)

- town (e.g. Birmingham)
- junction (e.g. M5S-A38N)
Page 82 of 122
K.6. Warning Screen
Figure K.6.1 – Warning screen
This screen is almost identical to the driving screen apart from two significant differences.
First the background has change to a deep golden colour, which will immediately grab the
driver’s attention – they will not need to look directly at the screen to understand that a
traffic warning has been received because of the distinct change of colour. The
information, through speech and text, simply informs them where the traffic is.
Second, the two buttons are for the driver to make a decision about the warning; green
accepts the warning and system automatically creates a new route from the current
location to the original destination taking into account the problem with the network,
where red ignores the problem and returns the driver to the previous drive screen.
While this screen will automatically ‘time-out’ after 30 seconds and return the user to the
previous driving screen, this is the only screen in which the driver has the option to
interact with the system while on the move.
Page 83 of 122
K.7. Final Screen
Figure K.7.1 – Final screen
The final screen simply informs the user through speech and text that they have arrived at
their destination. The pale yellow background was chosen to give a sense ‘acceptance’ –
that the system has finished its work. The green button ultimately just resets the system
to first Initial Location Search screen.
Page 84 of 122
Appendix L – Algorithm Pseudo-code
L.1. A* algorithm
While using this pseudo-code, based on the work of Heyes-Jones [18], it is important to
know the meaning of the following pieces of information:
To calculate F:
Knowledge of cost from one node to its successor is assumed (obtained from the
network). In this project, this can be the same or greater than the line of sight from node
to node, since roads can have corners and therefore overall have greater length than
others, even when traversing the same nodes.
To calculate G:
The additional ability to estimate the distance from one node to the goal node is present
by using the distance calculation algorithm.
Formula key:
F = Cost to current location

G = Estimated cost from node to goal
H = Sum of F and G
OPENList contains those tree branches yet to be explored.

CLOSEDList contains those tree branches already explored.
startAStar(Node node_goal, Node node_start) {
Create a node containing the goal state, node_goal

Create a node containing the start state, node_start
node_start.G = distance to node_goal

OPENList.add(node_start)
while (OPENList.size() > 0)

{
node_current = OPENList.getNodeWithLowestH()
if (node_current == node_goal)
finished, since we are at goal
do {
generate list of node_successor from node_current
for each (node_successor) {

set node_successor.cost = node_current.cost + cost to
successor from current
Page 85 of 122
if (node_successor on OPENList) and existing one is

better, discard successor and skip to next
if (node_successor on CLOSEDList) and existing one is

better, discard successor and skip to next
remove occurrences of node_successor from OPENList

and CLOSEDList
node_successor.parent = node_current
node_successor.G = distance to node_goal
OPENList.add(node_successor)
}
}
CLOSEDList.add(node_current)
}
return CLOSEDList
}
L.2. Distance calculation algorithm
// Calculates the distance between two locations

private static double distance(GPSInfo loc1, GPSInfo loc2) {
double lat1, lon1, lat2, lon2;
// defaults to miles could use K for KM or N for NM

String unit = M;
lat1 = loc1.getLatitude();
lon1 = loc1.getLongitude();
lat2 = loc2.getLatitude();
lon2 = loc2.getLongitude();
double theta = lon1 - lon2;
double dist = Math.sin(deg2rad(lat1)) * Math.sin(deg2rad(lat2)) +

Math.cos(deg2rad(lat1)) * Math.cos(deg2rad(lat2)) *
Math.cos(deg2rad(theta));
dist = Math.acos(dist);
dist = rad2deg(dist);
dist = dist * 60 * 1.1515;
if (unit == "K") {
dist = dist * 1.609344;
} else if (unit == "N") {
dist = dist * 0.8684;
Page 86 of 122
return (dist);
// This function converts decimal degrees to radians

private static double deg2rad(double deg) {
return (deg * Math.PI / 180.0);
}
// This function converts radians to decimal degrees

private static double rad2deg(double rad) {
return (rad * 180 / Math.PI);
}
Page 87 of 122
Appendix M – Java Classes and Relationships
Java Class
Diagram - Vehicle
1 Route 0..1 1 Result

-position : int -position : int
Vehicle 0..1
-position : int
1 Warning
1
1 -position : int
0..1
GPSInfo 0..1
-position : int
1 Network
0..1
-position : int
1
0..1
1
Node 0..1
-position : int
0..1
Roads
Edge
-position : int
-position : int
0..1
1
Junction Town
-position : int -position : int
Page 88 of 122
Java Class
Diagram –
Message Centre
VehicleWarning
-vehicleId : int
-edgeID : int
-roadName : string
-startEndDirection : bool
-newSpeed : double
-date : Date
Page 89 of 122
Appendix N – XML how-to
For the network.xml file, a pair of tags (apart from the standard first line XML tag) is
required into which the code for nodes and edges is placed. The ‘Topology’ tag acts as a
container for the abstract network objects.
<?xml version="1.0" encoding="UTF-8"?>

<Topology xmlns=http://www.opengis.net/app
xmlns:sch="http://www.ascc.net/xml/schematron"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:gml="http://www.opengis.net/gml"
xmlns:app="http://www.opengis.net/app"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.opengis.net/app networkExamples.xsd">

</Topology>
Figure N.1 – Extra network.xml tags
In the geometry.xml file, similar tags are required. In this case, the ‘gml:FeatureCollection’
tag acts as a container for the geometry objects with the addition of a ‘gml:boundedBox’
tag that acts as the boundary of the network – every other object must be within the box
created by these coordinates.
<?xml version="1.0" encoding="UTF-8"?>
<gml:FeatureCollection xmlns="http://www.opengis.net/app"
xmlns:sch="http://www.ascc.net/xml/schematron"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:gml="http://www.opengis.net/gml"
xmlns:app="http://www.opengis.net/app"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.opengis.net/app networkExamples.xsd">
<gml:boundedBy>
<gml:Box>
<gml:dmsAngle>
<gml:degrees direction="N">35</gml:degrees>
</gml:dmsAngle>
<gml:dmsAngle>
<gml:degrees direction="W">1.2</gml:degrees>
</gml:dmsAngle>
<gml:dmsAngle>
</gml:dmsAngle>
<gml:dmsAngle>
</gml:dmsAngle>
</gml:Box>
</gml:boundedBy>

</gml:FeatureCollection>
Figure N.2 – Extra geometry.xml tags
It is important to note that while these examples have and will make use of tags that are
part of the GML specification (those beginning with ‘gml:’), the GML language as a whole
Page 90 of 122
is much bigger than the features I have used, however these are the only ones required to
satisfy the needs of the development.
Page 91 of 122
Appendix O – XML Design
O.1. XML Schema
XML Schema Definition (XSD) files “provide a means for defining the structure, content and
semantics of XML documents” [19]. Before writing an XML file, albeit with GML data, XSD
files have to be created that defines the contents of the XML file itself. In this project, two
files have been created that represent 1) the abstract network, defining nodes and edges,
and 2) the geometry laid across this network representing towns, roads and junctions.
The network and geometry XSD files are written methodically, mapping the static data
portions of the class structure from section 9.1 into GML. The first portion of the files
defines the format of simple types as with Java, such as integers and strings. Secondly,
these are combined as complex types to match the data requirements from the class
structure and the formatting of the GML specification. As a node from the class structure
in section 9.1 is represented at the meta level by town, and at the abstract level by a
node, the XSD definitions for this is split across both files. For instance, the following is
found in the geometry XSD represents a node name:
<xs:element name=”gml:name” type=”stringtype”>
The contents of the XSD files mentioned below can be found in the project distribution
under the directory /XML.
O.2. Network XML
The network XSD and XML files will store the definitions and data that will format the
abstract network. The system network is formed from nodes and edges, which directly
relate to the Node and Edge classes from the class diagram in section 9.1.
A node can represent any individual point of reference, be it a town, a road junction or
something as granularised as an individual house. In this project, nodes are being used to
represent the locations of towns and junctions (road intersections). Underlined values in
the XML are those that are to be changed from node to node. A node is represented with
GML as follows:
<gml:Node gml:id="n1">
<gml:pointProperty>
<gml:Point>
<gml:dmsAngle>
</gml:dmsAngle>
<gml:dmsAngle>
</gml:dmsAngle>
<subnet>1</subnet>
<subnet>2</subnet>
</gml:Point>
</gml:pointProperty>
</gml:Node>
Figure O.2.1 – GML node representation
Page 92 of 122
An edge is a single link between two nodes. The edge is represented by its own id, and
references the nodes that it meets at its positive end and negative ends. An edge will be
used to represent one carriageway of a road in this project once geometry is created to
add to the abstract network. Again, those values underlined are the key ones that can be
changed.
<gml:Edge gml:id="e5">
<gml:directedNode orientation="-" xlink:href="#n3"/>
<gml:directedNode orientation="+" xlink:href="#n6"/>
</gml:Edge>
Figure O.2.2 – GML edge representation
O.3. Geometry XML
Once geometry is defined, nodes and edges defined in the abstract network become the
roads, towns and junctions of the final design. Each piece of geometry is defined in a
similar way, all with their own general and specific attributes.
Towns
There are many ways to represent a town; in this project a

town will be represented by a single node. However of course,
as is used in other route finding software such as Microsoft
Autoroute 2003, it would be possible to use a single to node in
the centre of a town to represent the town itself, then many
surrounding nodes for individual junctions and addresses - for
the purposes of this project this will not be practical due to time
constraints.
Figure O.3.1 – A town
<gml:featureMember>
<Town tid=”t1”>
<gml:name>Cardiff</gml:name>
<gml:directedNode orientation=”+”
xlink:href=”simpleNetwork.xml#n1>
</Town>
Figure O.3.2 – GML town representation
Roads
The majority of roads in the real world are two-way, in that

vehicles can travel between both end points in either direction. It Figure O.3.3 – A dual-
is possible for a road to be truly one-way though, such as a many carriageway (with
inner-city roads. To model both of these scenarios in GML, length in green)
multiple roads can be created along each Edge to represent the
different carriageways that cars can travel along. If no particular direction (orientation) is
specified in the XML for a Road, it is assumed that it is bi-directional. For instance, to
create a dual carriageway road, two roads would be required, with one positive and one
negative running between the same pair of nodes.
Page 93 of 122
The OpenGIS GML manual [5] highlights how important the ability is to distinguish
between the various carriageways of a road. For example, the average road speed may
differ in opposite directions on the same road, such as on a steep incline. This will be
particularly useful in the project, since it would be feasible for a road to have heavy traffic
in one direction but to be free flowing in the other.
To ease the job of assigning the normal average speed of a particular road, on the design
in Appendix F each road has been assigned a classification such as motorway or dual-
carriageway using a small selection of distinctive colours and patterns. Whilst the network
in this project is based on the road network of real life; at this level of detail it is not
possible for all roads to be included. As such, road classifications have been designated in-
line with their existence in reality as far as is possible, such as a motorway (the M5) from
the Midlands to the South-west of England.
While the positioning of the end points of the road is set by the terminating nodes of the
relevant edge and therefore does not intuitively require its own coordinates, it is possible
to set intermediate points that the road passes through, creating appropriate curves and
distances.
The following example represents a one way road.
<gml:featureMember>
<Road rid=”r1”>
<gml:name>A14E</gml:name>
<avSpeed>60</avSpeed>
<gml:directedEdge orientation=”+”
xlink:href=”simpleNetwork.xml#e1”>
</Road>
<gml:centerLineOf>
<gml:LineString>
<gml:dmsAngle>
</gml:dmsAngle>
<gml:dmsAngle>
</gml:dmsAngle>
</gml:LineString>
</gml:centerLineOf>
Figure O.3.4 – GML road representation
Junctions
Roads and junctions are not a natural part of the GML definition,
and as such are user defined. In terms of this project, a junction
represents the convergence of two or more roads outside of a
‘town’. Each road connecting to the junction is a separate entity,
and as such a road cannot ‘pass through’ and continue beyond a
junction. This breaking of roads will allow more granularisation in Figure O.3.5 – A
junction between three
the network design which will allow messages about congestion road sections
and traffic to be more localised to a particular section of road.
Page 94 of 122
<gml:featureMember>
<Junction jid=”j12”>
<gml:name>A14W-M6 Roundabout</gml:name>
<gml:directedEdge orientation=”-” xlink:href=”simpleNetwork.xml#e1”>
<gml:directedEdge orientation=”-” xlink:href=”simpleNetwork.xml#e4”>
</Junction>
Figure O.3.6 – GML junction representation
O.4. Data Access
While discussion of data access is strictly a development issue, it is worthy of note at this
point since it could have an impact on later risk analysis.
While GeoTools can provide a range of functions, the module of most significance for this
project is the GMLDataSource package which provides a collection of tools to intuitively
read, write and manipulate GML based data. Through a series of key methods to read and
write GML based data, the GeoTools suite will hook into the network data stores and allow
for a fast and light weight way of storing the information required to build a routable
network as originally specified.
Page 95 of 122
Appendix P – RAID
Page 96 of 122
Page 97 of 122
Appendix Q – Implementation Considerations
1) The project has been tested on a real PDA and minor inconsistencies were apparent
with the PDA’s Internet Explorer ability to render the HTML output. While a main
consideration of this project was to make the screen size similar to that of a PDA, it
related to size only and not the physical ability to display it. Since only minor changes
would need to be made if the front end was to be displayed on a PDA, this problem can
be left until actual deployment occurs.
2) There were some major differences between the abstract class diagram and the actual
implementation. A Java class diagram can be found in Appendix I to demonstrate this.
3) Originally there were meant to be individual JSP pages for each page of the front end.
At the implementation stage it proved to be difficult to maintain data in the system when
moving between each page. To resolve this, the pages were merged into one master
page, with a series of ordered ‘if else’ statements that, with the help of the backend,
decided which page to display. This also allowed code for such things as the logo at the
top of the page to be only written once.
4) It was found soon after development had began that it would have been far simpler for
the purposes of routing algorithms to use an SQL database. Generating data structures
(discussed in section 12) by hand in Java was complex and there were no integrity
constraints.
5) An unexpected feature became available as a consequence of development. It is

possible for vehicles to maintain different versions of networks, but still interact with each
other through the message centre. As long as edges, nodes, towns and junctions maintain
unique ids over each version of the network there will be no problem mixing versions.
6) To increase automation when adding new junctions to the system, the roads adjoining
a junction are calculated automatically and added to the junction name for display.
7) Added facility to the message centre so that it was able to centrally distribute unique
vehicle ids. This means that every new vehicle that starts up will obtain its vehicle id
remotely and each one will be individual.
8) The facility to select an output voice for the audio module in the system was added
relatively simply. Sets of audio were recorded by two people and stored under
sub-directories which are then selected through an extra parameter passed with the
request.
9) The audio output system was updated to better handle numbers, and with some extra
code can now read out in a natural way numbers up to 999,999.
Page 98 of 122
Yellow & Red: Motorway (75 mph)
White & Red: Dual Carriageway (70 mph)
Appendix R – Network design

Red: Primary Route (60 mph)
Yellow: Secondary Route (50 mph)
Grey: Narrow Road (30 mph)
16.8mi
Green tag: Section length
Blue & White arrow: One-way road (in direction of arrow)
49.7mi
mi
i
.6m
44.8
56
32.6mi
y
Wa
e
On
44 i
.3m
i mi .5m
27
8.9
27
.2
41.9mi
m
i
Page 99 of 122
i
.4m
10
35.1mi 43
i
5m
.6m
i
i
2m
Wa y
One
.
20
11mi
41.1mi
18
41.2mi
.4m
i
20.5mi
i
.1m
i
.4m
17
39
40
14
21.5
.7
mi
.6m
m
7m
i
i
One
Way
17.1mi
33mi
mi
32.1mi
7.2
18
m
i
40.8mi
i
2m
42mi
5.
22m
8.
6m
10
O
ne
35mi
i
mi
i
W
ay
One Way
40.2mi
7.3m
45
mi
i
76
.3m
i
9.7mi
mi
27.6
8.6mi
87.7mi
Appendix S – Testing Documentation and Results
S.1. System White Box Testing Results
Class Class Role Primary Incidents / Action Plan

com.digitalhen.apps. Provides access to GPS 1. Provide methods to allow GPS data
trafficlive.gps. data from GPS to be fed at regular intervals from
GPSDriver devices/simulator a ‘simulator’ thread, based on
Vehicle data.
com.digitalhen.apps. Download warnings from 1. Use system configuration to
trafficlive.messaging. Message Centre provide the base URL of the
MessagingClient Message Centre, allowing the URL
to be changed in the future.
2. Format URL for message retrieval
based on the Message Centre
servlet itself.
com.digitalhen.apps. Transmit warnings to 1. Format URL for transmission as
trafficlive.messaging. Message Centre with client.
MessagingTransmitter 2. Obtain History (object created as a
result) from Vehicle by adding a
reference to the Vehicle in the
transmitter object.
com.digitalhen.apps. Store details of the 1. Override equals method to make
trafficlive. connection between a Edges ‘match’ when their start and
networking.Edge pair of Nodes end nodes of one match those of
another (although these can match
alternately), to prevent storage of
the same edge twice.
2. Added ‘…IgnoreWarning’ methods
to allow routing algorithms to
ignore any warnings in the system
when selecting roads.
3. Added further ‘…Failsafe’ methods
to allow other objects to retrieve
Roads by first accepting warnings,
then ignoring them if no Road was
first returned.
4. EdgeAssociation object created to
store associated roads in both
directions.
com.digitalhen.apps. Stores and allows access 1. Allow network data to be loaded
trafficlive. to all aspects of the from simulated object and from
networking.Network system network. XML.
2. Added ‘getDirection’ and
‘getFullDirection’ to calculate the
direction from one node to the
next.
3. Added facility to check network
validity every time system is
started.
Page 100 of 122
4. Caching of distances between

nodes added with an additional
NodeIdPair object created as a
result.
com.digitalhen.apps. Stores details of the 1. Hashtable and appropriate
trafficlive. points on the network, methods added to handle storage
networking.Node such as junctions and of inter-locations.
towns. 2. Added facility to store parent node
id, for the calculation of the final
path.
com.digitalhen.apps. Taking a route object, 1. Added ability to step through in
trafficlive. calculates path between reverse from end node to start to
routing.AStar a start and end node. form a path, then reverse it to give
a resultant path.
com.digitalhen.apps. Stores details of start 1. Stores two copies of calculated
trafficlive.routing. and end of journey. route, one of which is for static
Route references (for instance to display
directions), and the second is for
dynamic references (for calculating
next node and edges for purposes
of navigation).
com.digitalhen.apps. Generates GPS data for 1. Added process to transmit and
trafficlive.simulating. the GPSDriver based on receive simulation data to and
GPSSimulator the Vehicle movements. from the Message Centre based on
speed over the current edge.
2. Reduce transceiver frequency to
an arbitrary fraction of each thread
execution to reduce load both on
the vehicle and Message Centre.
com.digitalhen.apps. Provides a basic amount 1. Generated before XML reading was
trafficlive.simulating. of network data for implemented to allow for adequate
GeotoolsSimulator testing. algorithm testing.
com.digitalhen.apps. Reads attribute pairs 1. Configuration relies on XML being
trafficlive.utils. (value against key for available on local web-server
Configurator each class) from XML. (issue still present).
2. Stored attribute pairs in one
AttributePairs object, then retrieve
based on a passed class.
com.digitalhen.apps. Parses XML network 1. Customised to match planned XML

trafficlive.utils. files. format.
NetworkConfigurator
com.digitalhen.apps. Allows searching of 1. ‘manySearch’ method added to
trafficlive.utils.Search various lists. facilitate the regular expression
searching of a hashtable for a
particular object (for node
matching).
com.digitalhen.apps. Data Access Object for 1. Simplified approach to parsing
trafficlive.utils.XMLDAO XML data, providing data by creating single method to
Page 101 of 122

various methods for convert URL object into XML

accessing different data. Document object, allowing many
other public methods to re-use the
same piece of code.
2. Created central object factory to
produce network topology objects
and its derivatives.
com.digitalhen.apps. To maintain vehicle 1. Added concept of state so vehicle,
trafficlive.Vehicle variables. and system, can accurately handle
warning related events.
2. Added facility to automatically
create history objects for each
edge as they are traversed.
com.digitalhen.apps. Converts latitude and 1. Created to facilitate the
trafficlive.ImageServer longitude into a requirement for application
graphical map. mapping based on locations along
a calculated path.
2. Added byte buffer to accurately
calculate the image file size before
outputting to browser (caused
errors prior to this being added).
com.digitalhen.apps. Converts string into an 1. Code caused output of numbers to
trafficlive.PlaylistBean MP3 playlist. be unnatural formed from
individual digits, so additional
WordProcessor utility class was
created to format numbers
correctly for playback.
com.digitalhen.apps. Provides interface 1. Methods and variables created as

trafficlive. between back and front required to facilitate the
TrafficLiveBean ends. requirements of the front end.
com.digitalhen.apps. Stores variables and 1. Clean up processes added to

trafficlivemessagecentre. runs threads required to thread to reduce server load over
MessageCentre service the time.
MessageCentreServer 2. Only individual warnings and
object. simulations held for each vehicle,
to reduce server load.
3. XML cached every minute rather
than per request, to reduce server
load.
com.digitalhen.apps. Acts as a transceiver for 1. Converted from bean to servlet, to
trafficlive. warning and simulation handle requests from multiple
MessageCentreServer data with vehicles. clients without interference.
2. Added facility to provide unique
vehicle ids to new clients to allow
simple identification of new
messages.
com.digitalhen.utils.web. Processes URL and 1. Added strip hash method to
Page 102 of 122

utils.URLProcessor returned altered version provide facility to remove pointers

depending on method from URLs in network XML files.
called.
Page 103 of 122

Page 104 of 122

Page 105 of 122

S.2. System Black Box Testing Results
Component Input Expected Results Error

found?
Networking / Edge getEdgeId() 1
(Network.getEdge(1)) getBestCost()
getStartNodeId() 1
getEndNodeId() 2
equals(Network.getEdge(1)) True
Networking / Road getStartEndDirection() True
(Network.getEdge(1).getBestRoad()) getEndStartDirection() True
getRoadName() True
getAverageSpeed() 75
getDistance() Appropriate…
getDistanceLong() Rounded as above…
Networking / History getEdgeId() 1
(Vehicle.getHistory()) getWarning() Warning object (when
one is in system, and
exception otherwise)
Networking / Network getNodeMatches(“lich”) Vector object, size == 1
getNode(1) Node object
getEdge(1) Edge object
getEdge(1,2) Edge object
getNewEdgeId() A value greater than
previous execution
getNodeSuccessors(2) Vector object, size == 2
calculateDistance(1,2) Appropriate…
calculateDistance(1, GPSInfo) Appropriate…
calculateDistance(GPSInfo, Appropriate…
GPSInfo)
getPositionOnEdge(GPSInfo, Appropriate… X – Originally
GPSInfo, distance) would only
work with
north-eastern
hemisphere
values.
getBearing(GPSInfo, GPSInfo) Appropriate…
getDirection(GPSInfo, GPSInfo) Appropriate… X – Returned in
accurate values
for a given pair
of locations.
Was a coding
mistake placing
letter in wrong
part of IF loop.
getFullDirection(GPSInfo, Appropriate…
GPSInfo)
validateNetwork() True
getEstimatedCostToNode(1,2) Appropriate and static
over multiple requests…
getWarnings(1, “M6 Toll”, true, Vector object, size == 0
false) unless warnings on road.
hasValidWarning(1, “M6 Toll”, False unless warnings on
true, 20.0) road.
getValidWarning(1, “M6 Toll”, Warning object. X – Throws a
true, 20.0) null pointer if
no warning
available,
problem still
Page 106 of 122
exists.
getValidWarningSpeed(1, “M6 Appropriate…
Toll”, true, 20.0)
hasAcceptedWarning(1, “M6 Toll”, False unless warnings on
true, 20.0) road which have been
accepted.
getAcceptedWarning(1, “M6 Toll”, Warning object. X – Throws a
true, 20.0) null pointer if
no warning
available,
problem still
exists.
getAcceptedWarningSpeed(1, “M6 Appropriate…
Toll”, true, 20.0)
Networking / Node getNodeId() 1
(Network.getNode(1)) getType() 1
getName() Lichfield
getFullName() Lichfield
getGPSInfo() Appropriate…
Routing / AStar findPath(Route) List object, size == 2
(Route is Lichfield to Birmingham)
Routing / Route getStartNodeId() 1
(Route is Lichfield to Birmingham) getEndNodeId() 2
getResult() Result object.
findPath() List object, size == 2
findPathEdges() List object, size == 1
getNextNode(GPSInfo) Appropriate…
hasCurrentEdge() True if vehicle has passed
a node on route, else
false.
getCurrentEdge() Edge object. X – Throws a
null pointer if
no edge
available,
problem still
exists.
hasNextEdge() True if vehicle has
another edge to pass
over, else false.
getNextEdge() Edge object. X – Throws a
null pointer if
no edge
available,
problem still
exists.
Utils / Configurator getConfigForClass(new Network(), Boolean object (false).

(Using standard XML file) "NETWORK_MODE")
Vehicle getGPSInfo() Appropriate…
getSpeed() Appropriate…
getVehicleId() 1
getRoute() Route object.
getNextNode() Node object.
getHistory() History object.
getState() 1
getSpeedThreshold() 20
Utils / Simulation getVehicleId() 1
(Created with values: 1, 1, M6, true, getEdgeId() 1
20 March 2003) getRoadName() M6
getStartEndDirection() True
Page 107 of 122
getDate() 20 March 2003

equals(new Simulation(…)) True
Utils / Warning getVehicleId() 1
(Created with values: 1, 1, M6, true, getEdgeId() 1
40.0, 20 March 2003) getRoadName() M6
getStartEndDirection() True
getNewSpeed() 40.0
getDate() 20 March 2003
equals(new Simulation(…)) True
Web / Utils / URLProcessor stripHash(URL) URL matching:
(URL is: http://test/me#1) http://test/me
Web / Utils / WordProcessor processWord(Word) Word matching: turn left X – Initially was
(Word is: turn left in 100 metres) in 1 00 metres unable to
handle any
numbers larger
than 20.
Facility was
added and it
handled all
number to
999,999.
Page 108 of 122

S.3. Route White and Black Box Testing Results
Scenario for Present on Suggested route to Navigated

algorithm network? test to satisfy successfully?
dynamic branching
One way road (A*). Yes Salisbury Æ Andover Yes, found
another route.
Multiple roads over Yes Southampton Æ Yes, took
one edge. Sandown fastest.
Multiple roads over Yes Southampton Æ Yes, took
one edge with Sandown secondary.
warning on primary.
Multiple paths to Yes Lichfield Æ Trowbridge Yes, took
same location. fastest.
No route possible to Yes Lichfield Æ London No, there was
destination, i.e. a no route as
disconnected town. expected.
Warnings on all roads Yes Lichfield Æ Bristol Yes, found a
over one edge. new route.
Warnings on all roads Yes Lichfield Æ Winchester Yes, ignored
over one edge with warnings and
no alternative. took fastest.
Page 109 of 122

S.4. Usability Testing Documentation and Results
Pre-test Orientation Script
The purpose of this script is to:
- Establish standardised preconditions for all test participants.

- Put all test participants at ease by informing participants that the work is under
test, not them.
- Ensure that all participants know what to expect during the test.
“
Thank you for agreeing to participate in this usability study of Traffic:Live! Before
we begin, I’d like to give a brief overview of the purpose of this study, what we will
be doing for the next 10 minutes or so. If you have any questions, please feel free
to ask these at any time.
The purpose of this study is to understand how users interact and understand the
interface and functionality of Traffic:Live! You are only here to help me assess how
well the interfaces do or do not fulfil your needs as a user. Therefore, any problems
found while performing the assigned tasks are viewed a system shortcoming, rather
than any basis for evaluating your skills as a user. Please relax, and feel free to
express any difficulties you may be having while following the tasks.
The study consists of a pre-test questionnaire, the aim of which is to establish some
background to your test results. Following this is an interface evaluation broken up
into two parts; a ‘stationary’ test using the first screens of the application, and a
second ‘dynamic’ test that looks at how easy the application is to use while you are
concentrating on something else (in this case, a computer game).
Throughout this study, it is very important that you verbalize your thoughts as you
complete each task - this is called “thinking aloud”. By doing this, you allow me to
assess the intuitive design of Traffic:Live! The follow-up questionnaire and
debriefing session will allow us to discuss some particular points regarding what
you thought of the interfaces.
At this point, the study will be complete. I would like to express my thanks for
taking part. If you would like a copy of the test results please let me know.
Page 110 of 122

Pre-test Survey
Before we begin, please fill out this short survey. The information provided will be strictly
confidential and will not be connected to your name in any way. Please circle the answer
that is most appropriate to you where applicable.
Question 1. Which age group do you belong to?
<= 17 18-22 23-28 29-45 >= 46
Question 2. Are you male or female?
Male Female
Question 3. What is your highest qualification?
<= Secondary School University >= PhD
Question 4. What is your current occupation?
______________________________
Question 5. How would you rate your experience of using the web?
Low 1…2…3…4…5…6…7…8…9…10 High
Question 6. How many hours driving do you do a week?
□ None / Not qualified
□ < 1 hour
□ 1 – 5 hours
□ 5 - 10 hours
□ > 10 hours
Question 7. How much familiarity do you have with navigation systems?
None 1…2…3…4…5…6…7…8…9…10 Lots
Question 8. Have you ever used a PDA (Personal Digital Assistant) before?
Yes No
Page 111 of 122

Test Tasks
Task 1 Description
Task Search for a start and end location
selected from a map.
Starting State Traffic:Live! main page
Successful Completion Criteria Participant has successfully searched
for two locations and found at least
one match for each.
Script Imagine you are in your car planning
a journey from one city to another.
Using the supplied map, choose two
locations and then enter part of their
names (for example “Lon” for
“London”) into the start and end
fields.
Once you have done this, search for

appropriate matches and write the
first few results below:
Start text:
End text:
Start results:
End results:
Page 112 of 122

Task 2 Description
Task Calculate the route between two
locations and display the directions.
Starting State Traffic:Live! confirmation page
Successful Completion Criteria Appropriate route and directions
found and displayed between start
and end locations.
Script By now you have successfully found a
selection of start and end locations.
Select the ones you originally chose
from the map and then calculate and
display the directions on screen for
that route.
List the key locations passed through

on the proposed journey:
Task 3 Description
Task Display the map for an intermediate
location on the obtained route.
Starting State Traffic:Live! directions page
Successful Completion Criteria Map found for interim location on
route.
Script Given your directions, use the
Traffic:Live! system to obtain a map
for one of the intermediate locations
for your journey.
Page 113 of 122

Task 4 Description
Task Switch the system into drive mode
and understand instructions given by
the system while playing the provided
game.
Starting State Traffic:Live! map page or Traffic:Live!
directions page
Successful Completion Criteria Warning message displayed.
Script Begin by switching the system into
drive mode. When this has been
completed begin playing the game
provided, but keep listening to the
instructions provided by the system
and enter the initial details below.
Next location:
Distance to next location:
At some point a warning will pop up

on screen and there will be an audio
warning. When this happens, write
down the details of the warning
below at which point this task finishes
and the next immediately starts.
Warning road:
Task 5 Description
Task Respond appropriately to the given
warning.
Starting State Traffic:Live! warning message
Successful Completion Criteria Successfully returned to driving
mode.
Script Respond to the on-screen warning as
you see fit.
Page 114 of 122

Post-test Questionnaire
Thank you for completing this usability test. Before you leave, please could you complete
these questions so that your reaction to the software can be best assessed. As before,
please circle the answer that is most appropriate to you where applicable.
Question 1. How helpful was the organisation of the Traffic:Live! application when it
came to completing the tasks in this test?
□ Very Helpful
□ Helpful
□ Neither Helpful nor Unhelpful
□ Unhelpful
□ Very unhelpful
Question 2. How difficult was navigating the Traffic:Live! application while completing
the tasks?
□ Easy, required no effort to complete the tasks
□ Required normal amount of effort to complete the tasks
□ Required more effort than normal to complete the tasks
□ Frustrating amount of effort required to complete the tasks
Question 3. Are you generally in agreement with the design of the Traffic:Live!
application when it came to using it for in-car navigation?
Yes No
Question 4. If not, what would you do differently to increases the usefulness of the
application?
Page 115 of 122

Quest ion 5. Please rate the follow usability factors.
© Digital Equipment Corporation, 1986.
Strongly Strongly
disagree agree
1. I think that I would like to
use this system frequently
1 2 3 4 5
2. I found the system unnecessarily

complex
1 2 3 4 5
3. I thought the system was easy

to use
1 2 3 4 5
4. I think that I would need the
support of a technical person to
be able to use this system 1 2 3 4 5
5. I found the various functions in

this system were well integrated
1 2 3 4 5
6. I thought there was too much

inconsistency in this system
1 2 3 4 5
7. I would imagine that most people

would learn to use this system
very quickly 1 2 3 4 5
8. I found the system very

cumbersome to use 1 2 3 4 5
9. I felt very confident using the

system
1 2 3 4 5
10. I needed to learn a lot of

things before I could get going
with this system
1 2 3 4 5
NB. Please only complete the following questions if you taking part as an experienced
user.
Question 6. Did you notice any unexpected results while performing the tasks (such as
an inappropriate search result for a query)?
Page 116 of 122

Question 7. Did any errors appear on screen while performing the tasks (such as
exceptions or HTTP errors)?
Question 8. Do you have any technical recommendations with regards to the

functionality of the system (such as a missing feature)?
Question 9. Do you have any technical suggestions for the user interface?
Page 117 of 122

Usability Testing Results
Participant Demographics
EP = Expert Participant
NP = Novice Participant
Pre EP1 EP2 EP3

Question (Expert)
Gender M M F
Experience using the web 9 10 9
Navigation system familiarity 4 8 5
Hours driving per week None / Not qualified 5 – 10 hours 5 – 10 hours
Used a PDA Yes Yes Yes
Pre NP1 NP2 NP3 NP4 NP5 NP6 NP7 NP8

Question
(Novice)
Gender M M M M F M M F
Experience 1 1 6 7 8 4 5 9
using the web
Navigation 7 8 10 3 2 5 4 5
system
familiarity
Hours driving 1–5 5 – 10 > 10 > 10 > 10 1–5 <1 5 – 10
per week hours hours hours hours hours hours hour hours
Used a PDA No No No Yes No No No Yes
Pre-test Q1 Total (Expert) Total (Novice)

17 and under 0 0
18 – 22 2 2
23 – 28 1 2
29 – 45 0 3
45 and older 0 1
Which age group do you belong to?
3
2.5
2 17 and under
1.5 18 – 22
1 23 – 28
0.5 29 – 45
45 and older
0
Total Total
(Expert) (Novice)
Pre-test Q3 Total (Expert) Total (Novice)

<= Secondary School 0 1
University 3 6
>= PhD 0 1
Page 118 of 122

What is your highest qualification?
6
5
4 <= Secondary
School
3
University
2
1 >= PhD
0
Total Total
(Expert) (Novice)
Test Accuracy Results
Task Completions % EP1 EP2 EP3

T1:ST 3 100% 1 1 1
T1:ET 3 100% 1 1 1
T1:SR 3 100% 1 1 1
T1:ER 3 100% 1 1 1
T2:Appropriate 2 66% 1 1
T2:Key Locations 2 66% 1 1
T3:Map 3 100% 1 1 1
T4:NL 3 100% 1 1 1
T4:DTNL 3 100% 1 1 1
T4:WR 3 100% 1 1 1
T5:Responded OK 2 66% 1 1
Time 6:30 5:25 7:15
% Complete 90.7% 100% 73% 100%
The average time taken by the expert users to complete the tasks was 6 minutes
and 24 seconds.
Task Completions % NP1 NP2 NP3 NP4 NP5 NP6 NP7 NP8
T1:ST 8 100% 1 1 1 1 1 1 1 1
T1:ET 8 100% 1 1 1 1 1 1 1 1
T1:SR 7 87.5% 1 1 1 1 1 1 1
T1:ER 6 75% 1 1 1 1 1 1
T2:Appropriate 8 100% 1 1 1 1 1 1 1 1
T2:KeyLoc 5 62.5% 1 1 1 1 1
T3:Map 4 50% 1 1 1 1
T4:NL 8 100% 1 1 1 1 1 1 1 1
T4:DTNL 8 100% 1 1 1 1 1 1 1 1
T4:WR 7 87.5% 1 1 1 1 1 1 1
T5:RespOK 5 62.5% 1 1 1 1 1
Time 10:23 9:25 6:24 7:56 5:10 8:26 7:01 10:00
% Complete 84.1% 82% 82% 82% 64% 100% 82% 100% 82%
The average time taken by the novice users to complete the tasks was 8 minutes
and 5 seconds.
Page 119 of 122

Post-test Feedback
ET1 ET2 ET3

How helpful? Very helpful Helpful Helpful
How difficult? Normal Normal Normal
Agree with design? Yes Yes Yes
Would use frequently? 4 3 3
Unnecessarily complex? 1 2 2
Easy to use? 5 4 4
Would need support? 1 1 2
Well integrated? 4 4 4
Too much inconsistency? 1 2 1
Would be quick to learn? 4 3 4
Cumbersome to use? 2 2 1
Felt confident? 4 4 3
Needed to learn a lot? 2 1 2
NP1 NP2 NP3 NP4 NP5 NP6 NP7 NP8

How helpful? Neither Neither Very Helpful Helpful Neither Helpful Very
Helpful Helpful
How difficult? Normal Normal Normal Easy Easy More More Normal
effort effort
Agree with Yes No Yes Yes Yes Yes Yes Yes
design?
Would use 5 2 3 3 4 2 3 3
frequently?
Unnecessarily 1 3 2 2 1 3 2 1
complex?
Easy to use? 3 2 4 4 3 1 3 4
Would need 2 4 1 3 2 1 2 2
support?
Well 4 3 4 4 5 2 3 2
integrated?
Too much 1 4 1 3 2 2 3 1
inconsistency?
Would be quick 4 3 4 2 3 3 4 3
to learn?
Cumbersome to 1 3 2 2 1 4 2 2
use?
Felt confident? 4 3 3 2 3 4 3 4
Needed to learn 1 4 3 2 2 4 3 2
a lot?
Page 120 of 122

Participant Comment Highlights
Task 1: Search for start and end location
EP1: Text could be larger, don’t think it would be that

easily readable in the car… otherwise I like it.
EP3: Possible could take a while to search if you allow one

letter searches!
NP2: I found it quite to find out what did what… but ah

yeah, there are pop ups. They seem to make it clear what
to do…
NP4: Search results aren’t in order… why not?
Task 2: Calculate the route between locations and display directions
EP1: No way to scroll directions – what if directions are too

large for the page?
NP2: Very quick response, really like that.
Page 121 of 122

Task 3: Display the map for an intermediate location
EP3: It’s not entirely obvious how to switch between maps.
NP4: Would be better if you could display the whole route.

Flicking between intermediate locations doesn’t
demonstrate the route very well.
NP6: I thought going left might bring up the next map in

the journey but it was the other way around.
Task 4: Switch the system into drive mode
EP2: Not really an issue with the program per-se, but

maybe call the ‘drive mode’ something a little bit more
obvious like navigate or something like that…
NP1: Very smooth switch intro drive mode. Might be nice to

have an option to display something OS coordinates for my
location though so I could compare it to real life OS maps.
NP5: Arrows aren’t relative to vehicle direction, so for

example if the arrow was telling me to drive South-West
and I was already driving that way I might get confused.
Task 5: Respond to warnings
EP2: Very bright, and very obvious.
EP3: Maybe make a way of responding by voice to the

messages.
NP7: Really liked the way this pops up and goes away.
NP8: Maybe some way of controlling how long it stays up

on the screen?
Page 122 of 122

Traffic Live: A Study of In-Car Satellite Navigation and GPS

Uploaded by

Document Information

Original Title

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

Traffic Live: A Study of In-Car Satellite Navigation and GPS

Uploaded by

Copyright:

Available Formats

Project III Henry Williams

Table of Contents Page No.

15.6. Usability Testing ......................................................................................................... 38

S.2. System Black Box Testing Results .......................................................................... 106

Conventionally, an in-car navigation system is installed in a car to provide route planning

1) It will create a Peer-to-Peer network between different users to allow the

1.2. Project Statement

The primary goals of this project are to:

1) Route planning between a particular pair of nodes across a network of them.

2) Develop a system of communication between individual vehicles on the road,

3) Demonstrate the use of technologies, that to me are new or relatively

• Extensible Mark-up Language (XML) for communications language

4) Make a simple and easy to understand interface and feedback system to

Possible secondary goals of this project are to:

Figure 2.1.1 – Hardware based route navigation

For each route finding application a variety of factors will be considered,

Each application is either commercially or freely available on the web or on

The following features were considered when reviewing each piece of

- Distances and times involved in the example routes

2.2.2. Results and Conclusion

Distance and time Route Instructions Interface

Distance and time Route Instructions Interface

In conclusion, a system combining the functionality of Tom Tom and

3.1. Standard Algorithms

3.2. Intelligent Algorithms

- Form a one-element queue consisting of a zero length

Figure 3.2.1 – Algorithm for A* [3]

3.3. Dealing With Changes

It is important to remember that regardless of what happens to the network, nodes

With this in mind, in my opinion it will be best, at least at first, to attempt to

One of the goals of this project is to implement a form of peer-to-peer communication

There are many ways for two peers to exchange information:

- WiFi (Wireless networking)

- directly (or at least through a third party messaging system)

Further details of each can be found in Appendix C.

Any system for input and output needs to be:

6.1. Geographical Mark-up Language (GML) for mapping

Figure 6.1.1 – GML example

6.2. Global Positioning System (GPS) for location

Table 6.2.1 - Example of a decoding table followed by an example sentence

As a result of research discussed in section 2 to 6, the following requirements have been

Primarily my system will meet these requirements:

8. Communication between vehicles must be able to take place using GPRS.

2. Allow the selection of intermediate nodes on route.

Vehicle - Front End

(3) (4) Message Handler

Vehicle System (22)

(11)(12) (7) GPS Logging

(13) (14) GPS

GeoTools Middleware (6)

(17) (18) (19)

Figure 8.1 – System Architecture diagram

9. Formal Backend Modelling

9.1. Use Cases

9.2. Activity Diagrams

Following on from each use case, a collection of activity diagrams “records

The activity diagrams can be found in Appendix H.

9.3. State Charts

The State Charts can be found in Appendix I.

9.4. Class and Relationships

A class structure is constructed by analysing the previous activity and state

Secondly, the class structure functions as a formal object-orientated definition of

The class models can be found in Appendix J.