Reading Time: 26 minutes

Introduction

Buses play a major role in the public transport service of the United Kingdom. Passengers using the service are dependent on knowing when the buses will arrive. Buses are prone to delays such as adverse weather conditions, traffic congestion etc. and this can result in passengers waiting for long periods at the bus stop. Out of date or missing timetables can also be problematic for passengers.

This project shall address these issues by developing a Real Time Passenger Information system which is available to the general public using modern technology such as Smart Phones, Computers, and Bus Displays.

Team Members

The team consists of two individuals who are both studying part time for an MSc in Advanced Technologies in Electronics. The first member is Kris. Kris has previously been awarded a BEng in Electrical and Electronic Engineering. The second member is Peter Mayhew who is sponsored by GE Aviation. Peter has previously been awarded a BEng in Electronics Engineering.

The main project work has been split accordingly:

Kris is responsible for the embedded system which consists of hardware and software.

Peter is responsible for the online web application development, sever side scripting, and database management.

Project Outline

This section of the report is concerned with reviewing Real Time Passenger Information systems, and why there is a gap in the market for smaller organisations.

Background & Issues

A study by Gabriela Beirao conducted with the general public showed that “Some infrequent users and non-users claim to lack information about the bus system and perceive public transport as difficult to use”(1). A report by Benjamin Gardner discussed that providing greater access to bus service information and more interactive services (e.g., real-time timetable information) may increase individuals’ perceptions of control with public transport (2). These studies demonstrate that there is a need to improve Real Time Passenger Information services.

There are several Real Time Passenger Information services available on the United Kingdom (UK) market such as Star Trak, Traveline and Advanced Communication and Information Systems (ACIS).

The Leicestershire County Council operated a 10 year old Star Trak bus tracking system which cost £3.8M. Their website reports “people often tell us they would use buses more if they knew where to find information about their local services” (3). This system was subsequently scrapped in 2010 due to passengers complaining that the bus stop displays were unreliable. The council are now replacing Star Trak with a new Real Time Passenger Information system costing between £500,000 to £1M (4).

Traveline is a nationwide public service in the UK which is funded by a government incentive plan to encourage people to use public transport. They are in partnership with local councils to obtain the latest bus timetables and utilise technology already incorporated into modern buses. Traveline employs Data Officers with a salary of £27,000 each, and they update a database with the latest bus timetable schedules.

Gloucestershire County Council use ACIS who provide intelligent transport products for the travel industry. A review of their system was found be to very comprehensive. The ACIS system allows the council to monitor the buses in real time, and to automatically generate reports such as on-time performance. However, their web application was found to be cumbersome to use and requires technical knowledge of either a bus stop reference number (i.e. 1600GL9057) or the road name where the bus stop is located. If the user does not know the area, then the website is very user unfriendly. A report published for Gloucestershire County Council shows that a capital budget of £2.9M and total revenue £1.4M was reserved over a 5 year period for the Real Time Information (RTI) system (5).

Infrastructure Cost for Commercial Real Time Bus Tracking

In order to gain detailed information about current systems in operation, two meetings were held with Gloucestershire County Council on the 26^th November 2010 and 3^rd December 2010. The meetings provided valuable information with regard to the structure of the ACIS system in addition to a breakdown of typical running costs (see Table 2‑1).

Large bus operators such as Stagecoach have invested more than £120million in state-of-the-art vehicles in the past three years (6). This includes modern ticket machines which have an inbuilt wireless communication system, see Figure 2‑1. This allows the bus to be tracked using Global Positioning System (GPS) and its positional data sent back to a control centre using General Packet Radio Service (GPRS). This technology also allows the driver to enter the route number which confirms that a bus has reached a particular bus stop, plus additional features to inform the driver of road accidents or adverse weather conditions. The cost to install a modern ticket machine with GPS/GPRS into a bus is reported by Gloucestershire County Council as costing up to £3,500.

This is a considerable cost for small organisations such as school bus services that typically don’t have a ticket machine or have an older model installed which doesn’t support GPS/GPRS. Therefore, we believe there is a gap in the market for a cost effective bus tracking system.

Description	Cost
Vehicle equipment. Wires, Antenna	£3,500
Information board at bus stops and installation code	£5,000
Running cost of information board, electric taken from street lighting	£200 per year
General Packet Radio Service (GPRS) data sent per year	£5 per year*
Professional Mobile Radio (PMR) licence per year	£200
Project Management by ACIS	10% of total cost
Bus Display Site survey	£750
Bus Display from ACIS	£5,100
Bus display: Fabrication of brackets by ACIS	£300
Data configuration	£300
Annual maintenance	£450/year
Real time SMS interface	£26,000**

Table 2‑1 Cost Breakdown

* Not validated

** Gloucestershire County Council have not paid for SMS service and therefore this feature is not available. Currently the only form of real time bus tracking is via the online website.

$F:\My Documents\Microsoft Office\Education\University\Postgrad\Year 2\Group Project Challenge - UFEEUC-15-M\Glouscestershire Council\Peter Mayhew Data Compilation\Documents\Ticket Machine Info\Wayfarer TGX.jpg$

Figure 2‑1 Ticket Machine (Courtesy Gloucestershire County Council)

Project Placement

The purpose of this project is to develop an online bus tracking system that is aimed at companies who do not have the capital or government backing to fund commercial systems currently available on the market. Existing systems require significant infrastructure and advanced ticket machines in order to operate.

Producing an affordable solution will open the market to privately run companies that would otherwise be priced outside of the market such as those that operate school bus routes and out of town areas.

The developed system will address the issues experienced with existing website usability problems and focus on achieving a vast improvement in the ease and experience of travelling by bus on a day to day basis.

Aims & Objectives

Aim:

Produce a low cost bus tracking system with an online real time interface.

Objective 1:

Conduct market research to establish user requirements for new tracking system.

Objective 2:

Produce embedded hardware system to transmit position information to remote storage location.

Objective 3:

Create online interface for users to access real time bus location data.

Objective 4:

Analyse prototype system performance and usability.

Market research

Developing an online bus tracking system that meets the demands of potential users is critical to the success of the project. A bus company will have an outlay associated with the cost of the bus tracking system which will need to be recuperated in part through additional travellers who are enticed by the benefits of the online service. Therefore, the majority of potential customers must be satisfied with the additional service provided in order for the bus company to observe a benefit.

Market research has been used to gather the requirements of potential users through the use of an online and paper questionnaire. The questionnaire consisted of 9 compulsory and four optional questions. A total of 102 responses were received, made up from a mixture of students, lecturers and work colleagues.

A selection of four questions and the results is included below.

How frequently would you like the online data refreshed?
How would you prefer to enter your current location?

Enter Current Location	Majority Preference
GPS Location from Device	1
Post Code	2
Street Name	3
Longitude & Latitude	4

How would you like the online tracking data presented?
(Please number 1-3 in order of preference, 1 being the most preferable)

Website Layout	Majority Preference
Simple interface showing arrival time of bus at chosen stop	1
Graphical map showing bus location with route to chosen bus stop	2
Graphical map showing bus location	3

Which platform would you most likely use to access the real time bus tracking interface?

Analysis of the results has fed directly into the design of the bus tracking system to ensure the focus is on meeting the requirements of potential users. In the following two sections of the report the data from the market research will be discussed in relation to design decisions made.

This research completes objective 1.

Embedded Hardware/Software Development

This section of the report is concerned with the development of the embedded hardware/software device that operates as part of the bus tracking system. The hardware residing on the bus will be referred to as the target while the remote server application will be referred to as the host.

Requirements

After discussions with Gloucestershire Bus Company and analysis of the market research had been taken into consideration a list of ten target system requirements was formed.

The requirements of the target system are as follows:

Operate from 24V bus power supply with protection from current surges during engine cranking
Ability for driver to enter bus ID number
Option to select if the bus is in or out of service
Detect current position of bus using GPS
Transmits bus information wirelessly to remote server at least every minute
Low cost (< £200)
Battery backup
External Antennas
Indictors to show current state of system
Small form factor with minimal installation

The purpose of this project is to produce a functioning prototype system that can demonstrate the bus tracking concept. This means that some of the requirements carry greater importance than others. For example, the size of the prototype system is not of great importance because it is expected that extensive development is required to transform the prototype system into a commercial product. System cost per unit will decrease as a product reaches mass production. However, if the technology used has a high value initially then achieving a lost solution under £200 will not be feasible.

Wireless Data Communication

Due to the nature of this project, transmission of data from the bus tracking system to the remote server must be established via wireless communication. Many technologies are currently available on the market each with different merits. Selection of the most appropriate technology was based largely on network coverage and data charges.

Research revealed two technologies which satisfy the project requirements. They are General Packet Radio Service (GPRS) and ORBCOMM. GPRS is a data packet service that operates using the popular second generation (2G) Global System for Mobile communications (GSM). All mobile phones within the UK operate using GSM.

ORBCOMM is a company that offer a hybrid system consisting of a GSM based service in addition to satellite communication.

“The ORBCOMM network uses low-Earth-orbit (LEO) satellites to provide cost-effective tracking, monitoring and messaging capabilities to and from anywhere in the world.”(7)

The main benefit of ORBCOMM is the ability to function using satellite communications when standard telecommunication system coverage is not available.

Network coverage is very important to ensure real time bus position data can be uploaded to a remote server reliably. Figure 4‑1 is a map of the 2G coverage for the entire UK as of Q1 2008. Analysis of the map shows that the vast majority of the UK has 2G coverage with a minimum of one operator while most mainland geographical areas have two, three or four operators.

Figure 4‑1: Map of 2G mobile phone geographic coverage in the UK(8)

Data charges for ORBCOMM are not readily available on a per Mbyte basis however, mobile operators such as O2, T-Mobile and Vodafone typically charge around £1 per Mbyte.

GPRS has been selected for use in this project because 2G network coverage is very high throughout the entire UK. The use of satellite communications provided by ORBCOMM would only be beneficial in very remote areas where bus services may tend not to operate.

Hardware Architecture

Selecting the most appropriate target hardware setup is crucial to the success of the project as there is limited time to produce a working prototype system. Development of bespoke hardware such as a multi-layer Printed Circuit Board (PCB) is not practicable with the time and resources available. For this reason, efforts were focussed on establishing a system that consists of Commercially off-the-shelf (COTS) items that require little integration and subsequently reduce the overall system development time.

A top level view of the proposed target system architecture has been included in Figure 4‑2. This diagram shows the target hardware mounted in a bus transmitting the current location via GPRS link to a mobile base station. The mobile base station operated by a commercial network provider forms the connection to the internet. Data is then transferred via a GET request to a remote server and stored in a data base for processing.

Figure 4‑2: Target System Architecture

Extensive research has been carried out into suitable hardware solutions that comply with the target hardware requirements. Many options were initially discarded after discussion between team members due to the complexity and hardware manufacture required.

The two most suitable solutions are described below:

Hardware Option 1: Modular Embedded

This hardware setup involves the use of a microcontroller development board that interfaces with two external peripherals and several General Purpose Input/Output (GPIO) devices. A microcontroller communicates with an external GPRS modem via RS232 UART and an external GPS receiver via Serial Peripheral Interface (SPI) bus. Interface connections are made via a development board expansion header. A Binary Coded Decimal (BCD) switch is used to select the current bus ID number and a toggle switch is used to define the current status of the bus. LED indicators display system status to the user.

Figure 4‑3 is an example hardware setup for option 1 with all major components shown.

Figure 4‑3: Option 1 – Component Hardware

This setup requires significant time and resource before a functioning system can be established. Initially all components require connection to the microchip board then embedded C code must be written to test the GPRS modem and GPS receiver individually. Once data can be retrieved reliably an application to sequence the upload of GPS position via the modem is required.

Hardware Option 2: EZ863-GPS

This hardware setup is based around an existing COTS product called the EZ863-GPS unit manufactured by Gatetel. This packaged unit has a GE863-GPS (Figure 4‑4) chipset manufactured by Telit which consists of a combined GSM/GPRS modem with on-board GPS receiver.

Figure 4‑4: Telit GE-863 GPS Modem (9)

A special feature of the Telit device is the addition of an integrated Python Script Interpreter.

“The Easy Script Extension is a feature that allows driving the modem internally, writing

the controlling application directly in the Python high level language.” (10)

There are several benefits of using this feature with the main being that no external microcontroller is required to automate the hardware. This reduces the number of hardware components as all required peripherals are present in the single chipset. The device has a number of GPIO lines that can be interfaced with the same GPIO hardware as in option 1 such as the bus ID switch.

Figure 4‑5: Option 2 – EZ863 Hardware (11)

Option 2 based on the COTS EZ863-GPS device has been chosen as the hardware architecture as this will provide the most rapid and reliable method of establishing a prototype system. The product is readily available at a cost of around £150 including GPS/GSM antenna and battery pack. It is thought that the unit cost can be reduced to around £80 if a custom PCB is manufactured and a bulk purchase of the Telit chipset is made.

Wireless Communication Reliability

The main challenge experienced during the development and testing stage was achieving reliable periodic packet transfer to the remote server. It was found that the system would operate for many hours without a packet loss during static bench tests. When conducting field tests, while walking or driving, it was found that the system would randomly stop transmitting packets. The EZ863 device has insufficient memory to record data such as the server response and modem status. Instead a field test was conducted using a laptop connected to the EZ863 to view the raw data output.

It was discovered that as signal strength varied and exchange between mobile cells took place, the data connection to the remote server could fail. The failure caused the Telit modem to remain in data mode as the connection was not closed correctly. Significant time was spent to eradicate this issue and a solution involving a retrial period of packet upload was implemented. If upload failed entirely then a special escape sequence is sent to the modem to force closure of the data connection with the mobile operator. The challenging part was establishing the root cause of the problem and then testing possible solutions. Each re-trail of the system required a field test as static bench tests were not sufficient to examine network reliability.

Figure 4‑6 is a screenshot of a field test where system upload failed.

Figure 4‑6: System Failure

is a screenshot of a successful field test without system failure.

Figure 4‑7: Fully Operational System

Successfully producing a system that communicates location data to a remote location completes project objective 2.

Web Based Software Development

The information transmitted by the EZ863-GPS Device needs to be clearly presented to the user. The questionnaire results demonstrate that the public have a preference to view the bus information via a smart phone, personal computer, or a bus display. Several web applications were considered and are discussed in this section of the report.

iPhone/Symbian App

iPhone, Android and Symbian apps are very popular for mobile phones, however, they are specifically designed for a given operating system. Therefore, several platform specific applications would need to be developed to maximise our audience. This is outside the scope of the project and is not recommended.

Figure 5‑1: iPhone (Left) Android (Right

Internet Browser/Web Application

There are many web browsers available with the most popular being Internet Explorer 26.6%, Firefox 42.8%, Chrome 23.8%, Safari 4.0% & Opera 2.5%.(12). The web browsers use HyperText Mark-up Language (HTML) as the basic building language for web pages and describe how a document is formatted. Standalone HTML cannot respond to the user, it cannot make decisions or perform automated tasks (13). Standalone HTML is therefore not suitable for the bus tracking system since the web application for this project requires interactivity from the user. Therefore, additional technology is required.

Technologies such as Flash player, Microsoft Silverlight and Java Applets were also considered. However, they were not immediately available for all platforms and therefore not recommended for the bus tracking system.

HTML can embed client side scripting languages such as JavaScript. JavaScript allows interaction with the user, can perform repetitive tasks and is the native language for the Google Map API. JavaScript exceeds the HTML limitations and is critical to the design of the bus tracking system. Therefore, JavaScript shall be implemented into the web application.

Since the geographic position of the bus constantly changes, the webpage needs to retrieve data from the server asynchronously and dynamically update the webpage with the latest bus position. Since JavaScript is executed at the client side, it cannot read data directly from the database on the server. However, Asynchronous^[2] JavaScript and XML (Ajax) can retrieve data from a server in the background without interfering with the user. This is achieved via an XMLHttpRequest object to read data-interchange formats such as Extensible Mark-up Language (XML)^[3] for parsing. An example of Ajax is shown in Figure 5‑2. When the client performs an XMLHttpRequest the server needs to generate a XML file based on latest data stored in the database.

Figure 5‑2: How Ajax Works (14)

A major advantage with using Ajax is the asynchronous exchange of data between the web browsers whilst avoiding a full page refresh. This shall reduce the required bandwidth and improve the responsiveness and user experience of the web application.

A disadvantage of using XMLHttpRequest is a security restriction enforced by the web browsers known as “same origin policy“(15). This presented a design issue explained in section 5.8.

HTML 5

HTML 5 is the latest revision of the HTML standard, and this shall include a new Geolocation API. This API defines how a client side platform can determine its location using several means including Internet Protocols Address, Wi-FI / Bluetooth Migration Authorisation Code (MAC) Address, RFID, Wi-Fi, GPS and GSM/CDMA cell ID’s (16)(17).

HTML5 is supported by Mozilla Firefox 3.5, Opera 10.6, Google Chrome 9 and will be incorporated into the majority of web browsers in their next release. However, until the majority of the population use a browser which supports HTML 5, using this technology may reduce our target audience.

Mapping Applications

There are several online mapping services available such as Google Maps, Yahoo Maps, OS Maps, and Bing Maps. Each of the web mapping services has an Application Programming Interface (API) which defines a set of specifications to configure the web mapping services.

Since the bus tracking system is aimed at being low cost, an important consideration is the cost of the mapping service. Table 5‑1 shows a comparison of several mapping API’s. Some of the API’s are free, whereas others charge a yearly fee. Map Point provides additional services such as shortest distances and shortest time which is not provided by the free services. However, with an additional Haversine Algorithm, we can manually calculate the great-circle distances between two points on a sphere using longitude and latitude. This algorithm has been incorporated into our web application.

Table 5‑1: Map site comparison (18)

The Geocoding service is the process of finding geographic coordinates (longitude & latitude) from street names or post codes. These map providers enforce a rate limit on the Geocoding service requests per day to prevent abuse or overloading their servers. Three major mapping providers were compared as shown in Table 5‑2. Whilst these limitations are considered for our bus tracking system, they pose a low risk to the project due to the projects relatively low scale.

Service Provider	Geocodes / Day / IP Address	Page views / day / Application	Cost
Google map(19)	2,500	500,000	Free
Yahoo(20)	5,000	50,000	Free
Bing Maps(21)	Unknown	50,000	Free
Bing Maps for Enterprise	Upon request	On Application	On Application
Google Map Premier (22)	100,000	Unknown	£6,000
Google Map Enterprise (23)	Unlimited	Unlimited	£10,000 – £250,000

Table 5‑2: Mapping Service Limits

Server Side Scripting

Server side scripting is defined as a user’s request that is performed directly onto the web server using a server side script engine. Two common server side script engines considered were Active Server Pages (ASP) hosted by a Windows Server, and Hypertext Pre-processor (PHP) hosted by a Linux Server. The group decided to use ASP since a group member already had access to a Microsoft Server.

ASP allows the execution of scripting languages, such as VBScript, Jscript, PERL, or Python. The advantages of using ASP are

HTML forms submitted by the user (for example submitting an address) can be queried by the server and a programmed response returned.
A database can be accessed with its results returned.
Website is dynamic. This allows contents to change such as the bus position
Track multiple users navigating through pages using a unique session ID
Code is more secure since it cannot be viewed on the web browser.

Database Storage/Manipulation

Information generated by the EZ863-GPS Device is transmitted wirelessly over GPRS to a server, and then parsed. Since the server memory is volatile and of limited storage capacity, alternative storage methods are required. Databases are commonly used to store information permanently on the server. Typical databases include MySQL, SQL Server, Access, Oracle, and Sybase. Generally MySQL is used by online businesses due to its higher performance, higher reliability, and higher flexibility whilst maintaining a low cost due to being open source.

There are a number of limitations using Microsoft Access database such as a maximum file size of 2 GB^[4], and a limit of 255 concurrent users (24). Whilst a MySQL database is preferable for a full scale development, the Microsoft Access database limitations does not pose a risk for the purposes of this project and is readably available to the students during development without additional expense. It is recommended to not exceed 150 simultaneous connections with a Microsoft Access Database as it reduces performance (25). A decision was made to close down the database connections immediately after being used, which allows resources to be reallocated. Therefore, this limitation does not pose a risk for our small scale model.

Receive Data from Mobile Network via GET Requests

A custom server side script was developed to receive the EZ863-GPS Device parameters transmitted over Hypertext Transfer Protocol (HTTP) using GET requests. The GET request allows information to be sent from a client to a server by adding parameters to the end of a Uniform Resource Locator (URL) e.g. www.mayhew.me.uk/Page.asp?Bus=”South-West”. This would send a parameter called “Bus” with the information “South-West” which can be parsed by the server side script and stored in the database.

The following parameters were parsed from the URL and stored into the database.

Code	Description	Format
UTC	UTC Time	hh.mm.ss
latitude	Latitude	ddmm.mmmm N/S
longitude	Longitude dddmm.mmmm E/W	dddmm.mmmm E/W
hdop	Horizontal Dilution of Precision:	x.x
altitude	Altitude – mean-sea-level	xxxx.x
fix	Fix	1 Invalid Fix, 2 2D fix, 3 3D fix
cog	Course over Ground (degrees, True)	ddd: 000 to 360 degrees, mm 00 to 59 minutes
spkm	Speed over ground (Km/hr)	xxxx.x
spkn	Speed over ground (knots)	xxxx.x
date	Date of Fix	ddmmyy
nsat	Total number of satellites in view	nn
bus	BusNumber	xxxxx
status	Bus status: In Service or Out Of Service	1 or 0
key	Security key	5S`I95Z\|Y2B55rpnZ7CWW^u]6243\|

Table 5‑3: GET request parameters

The security key is only known by the server side script and the EZ863-GPS Device. This allows the server side script to determine whether the string is authentic. If the security key does not match, then the data is not processed by the server side script and returns a predefined error message. This is a preventative action against abuse, for example inserting false bus information into the database.

Top Level Architecture with Interconnects

Adobe Dreamweaver CS4 was used for the development of the website application.

Two architectures were considered for the web application architecture, as shown in Figure 5‑3.

Method A requires the user to submit the form twice, however Method B only requires the user to submit the form once, and the server returns the results. Hence, Method B reduces the number of “mouse clicks” and is the preferred option. However, Method B could not be implemented into the design due to the ‘same origin policy’.

“The same origin policy prevents a document or script loaded from one origin from getting or setting properties of a document from another origin” (15) (26).

We can only use Method B by requesting a secure connection with Google’s Server, which is charged. Therefore, Method A has been used for the web application.

Google Server

Server & Database

Client side Computer

Google Server

Server & Database

Client side Computer

Figure 5‑3: Method A (left): Method B (Right)

Web Application Performance

An earlier version of the web application suffered from a reduction in performance as the number of EZ863-GPS device packets was submitted. The root cause was due to the amount of data sent over Ajax, but more significantly the number of bus markers displayed on the Google map. The number of bus markers could be reduced using an interface called Market Manager; this is an interface between Client and Server application which manages the number of markers shown on the map at a given zoom level (27). After reviewing the questionnaire the group decided to show only three markers: the latest bus position, and the two bus stops. This reduced the risk of performance issues with the web application and ensured the map remained legible.

Web Browser Compatibility

A web browser is required to display HTML on a user’s display, and each web browser may interpret the HTML differently. In addition, JavaScript can also be interpreted differently between web browsers. However, rather than incorrectly formatting the page, a JavaScript error can result in the script not executing, an error message or may crash the web browser.

Therefore, the web application must be tested on several web browsers to minimise any compatibility issues.

The web application will require several scripting languages to allow the integration of the client side and server side and database. A solid understanding of the scripting syntax is required to ensure the successful completion of the web application.

The client side application had numerous technical challenges due to different standards adopted by web browsers.

During the development stages, a technical issue of the Ajax script was found when using Internet Explorer. The root cause was Internet Explorer caching the Ajax data. This was resolved by appending the date and time to the end of the URL string submitted, resulting in a unique URL on each request. This issue has also been documented in the Microsoft support pages (28).This issue was not present in Firefox, Chrome, or Safari.

The web application has been successfully designed and developed for users to access real time bus location data. Therefore, we have successfully completed objective 3 of this report.

Systems Testing & Validation

A full system test has been completed to assess the reliability of the embedded tracker and online web application. This required a custom interface enclosure with bus ID, bus status and status indicators to interact fully with the web application. During testing, a PC desktop recorder was used to video the web application in operation.

Figure 6‑1 shows the tracker system installed in a car ready for field test.

Custom Tracker Interface

Tracker Install

Figure 6‑1: Tracking System Installation

Playback of the desktop video showed the entire system operating correctly.

Performance Reliability

To assess the packet upload reliability, a series of field tests were conducted over the period of seven days. Each day a trip was completed and the number of packets received by the server during a period of time was stored using a custom admin page as part of the bus website. Market research revealed that potential users of the system require a location update every minute. To ensure the performance of the system meets the demand a packet is uploaded every 20 seconds depending on network response time. The following graph (Figure 6‑2) presents the reliability of the system by calculating the number of dropped packets per day as a percentage of the theoretical maximum.

Figure 6‑2: System Performance Tests

Analysis of the results shows that the system achieves a minimum of 90% packet upload success rate and an average of 95% over a total of 10 tests. It was noted during testing that the performance of the system is subject to weather conditions. On the lowest performing day (25/02/11) the weather was very wet and cloudy causing GPS signal strength to reduce significantly.

The left image of Figure 6‑3 shows the GPS receiver in the windscreen of the car during performance testing. This antenna is not optimal and performance increases could be achieved with a different antenna. The right image of Figure 6‑3 shows a high gain antenna that is used by Gloucestershire Bus Company.

Figure 6‑3: GPS Antenna Types

Web Site Compatibility Test

The web application has been tested in several web browsers and platforms to ensure compatibility. The results in Appendix sections & show that seven of the eight web browsers tested were compatible. The failures reported were isolated to Internet Explorer 6 which does not support some of the web standards required in our web application. Since only 3.8% of the population use Internet Explorer 6 this is not considered a significant issue (12).

A complete system test involving real GPS data and live web site was conducted as follows:

A local and destination address was entered and bus stop locations selected as shown in Appendix section 12.3. The bus tracker was installed in a car and driven on the route to the destination bus stop. The website presented the icon of the bus moving and calculated the distances between the bus and local / destination bus stops.

The validation of the web application is therefore a success and completes objective 4 of this report.

Future Work

To validate the reliability and usability of the prototype system, a trial system could be offered to a bus company for evaluation. Feedback gained from this trial will provide valuable information as to whether a commercial system is viable.

Embedded Hardware/Software System

To progress the hardware system further, a custom PCB to house the Telit GE-863 GPS device is required. This can then directly interface with the bus id input and status switches. The purchase of multiple Telit devices and custom PCB will reduce the unit cost of the system dramatically below that of the COTS EZ863 product.

Achieving higher reliability can be accessed using various antenna types. Installation of the system within an operational bus will provide valuable reliability results.

Web Based Software System

Future development could include SMS support to automatically alert the user when the bus is reaching their local bus stop, so the user does not need to keep checking the website.

The questionnaire shows that there is a majority preference for users to determine their location using the GPS location of their device. Future development could include implementing HTML 5 into the web application, as discussed in paragraph 5.3. This would allow users without GPS to automatically determine their location and therefore improve the web application usability.

Finally, Classic ASP has been replaced by the ASP.NET web application framework a number of years ago. Development time could have been significantly reduced by using the inbuilt libraries as outlined below.

Project used: Classic Active Server Pages (ASP)

Used to dynamically generated web pages

- Last major release November 2000
- Now superseded by ASP.NET framework
- Limited controls and class libraries available

Future use: ASP.NET

- Also allows dynamically generated web pages
- Better state management. To track users
- Better Performance
- Improved run-time error handling
- Extensive set of controls and class libraries

Project Execution

Division of Project Work

Once a clear project outline was established the technical work was split between members based upon personal interest and expertise. More general tasks such as conducting the market research was completed by both group members because it was deemed important to capture the thoughts of the group.

Project Progress Review

Semester 1 progressed well with the development of a dummy GPS system uploading predefined coordinates to a basic Google map web page. The planned work for semester 2 involved the upload of true GPS coordinates to the web application that displayed live bus stop location and position of bus. The level of complexity required to implement the desired system features was underestimated causing excessive time to be consumed.

The EZ863-GPS hardware functioned without failure during static bench tests however, during field tests the handling of the wireless communication was found to be unreliable.

Significant time was spent resolving this issue with an achieved reliability of 95% upload success.

The work was completed successfully and a system exhibiting all the main features was developed. In a commercial setting the project would probably be over budget in terms of man hours and this highlights the difficult problem of estimating the work load associated with a particular project.

Conclusions

A fully operational online bus tracking system has been produced with an average location upload reliability of 95%. Several meetings with a major local bus company have provided valuable information with regard to the infrastructure and expenditure associated with commercial bus tracking systems. Market research has been conducted to tailor the design of the system to satisfy potential users.

The outcome of the project is a success. With further development and backing a commercial low cost bus tracking system could be made fit for market.

References

1. Understanding attitudes towards public transport and private car: A qualitative study, Transport Policy. Gabriela, Beirao. Issue 6, Pages 478-489, November 2007, Vol. Volume 14. 0967-070X.

2. What drives car use? A grounded theory analysis of commuters’ reasons for driving, Transportation Research Part F: Traffic Psychology and Behaviour. Benjamin, Gardner and Abraham, Charles. Pages 187-200, May 2007, Vols. Volume 10, Issue 3. 1369-8478.

3. Council, Lancashire. Local Bus Information in Lancashire. lancashire.gov.uk . [Online] [Cited: 9 March 2011.] http://www.lancashire.gov.uk/corporate/web/view.asp?siteid=4404&pageid=20864.

4. Maclean, David. Companies offer to improve Leicestershire’s flawed bus tracking system. This is leicestershire. [Online] [Cited: 7 March 2011.] http://www.thisisleicestershire.co.uk/news/Companies-offer-improve-flawed-bus-tracking/article-2750188-detail/article.html.

5. Medus, Colin. GREATER BRISTOL BUS NETWORK: MAJOR SCHEME SUBMISSION FOR FULL APPROVAL. [Online] 6 March 2007. [Cited: 08 02 2011.] http://www.n-somerset.gov.uk/cairo/docs/doc14464.htm.

6. plc, Stagecoach Group. About Us. Stagecoachbus.com. [Online] [Cited: 11 March 2011.] http://www.stagecoachbus.com/aboutus.aspx.

7. ORBCOMM. Our Network. ORBCOMM. [Online] 2011. [Cited: 03 03 2011.] http://www.orbcomm.com/our-network-overview.htm.

8. Ofcom / GSM Association / Europa Technologies. Telecoms Charts. Ofcom. [Online] 2008. [Cited: 03 03 2011.] http://stakeholders.ofcom.org.uk/market-data-research/market-data/communications-market-reports/cmrnr08/telecoms/.

9. Telit Wireless Solutions. Telit GE863-GPS Datasheet. Telit Wireless Solutions. [Online] 2010. [Cited: 01 03 2011.] http://www.telit.com/module/infopool/download.php?id=162.

10. —. GE863-GPS Embedded. Telit Wireless Solutions. [Online] 2010. [Cited: 01 03 2011.] http://www.telit.com/module/infopool/download.php?id=617.

11. M2M Platforms. EZ863-PY. [Online] 1 2 2011. [Cited: 1 2 2011.] http://www.m2m-platforms.com/data.php?group=p&subj=730.

12. W3schools. W3schools. [Online] [Cited: 20 02 2011.] http://www.w3schools.com/browsers/browsers_stats.asp.

13. Moncur, Michael. Sams Tech Yourself Javascript in 24 Hours. s.l. : SAMS, 2002. 0-672-32406-7.

14. AJAX Introduction. w3schools.com. [Online] [Cited: 28 February 2011.] http://www.w3schools.com/php/php_ajax_intro.asp.

15. XMLHttpRequest W3C Candidate Recommendation 3 August 2010. W3C. [Online] [Cited: 27 February 2011.] http://www.w3.org/TR/XMLHttpRequest/.

16. W3C Geolocation API. Wikipedia. [Online] [Cited: 22 February 2011.] http://en.wikipedia.org/wiki/W3C_Geolocation_API.

17. Geolocation API Specification. World Wide Web Consortium. [Online] [Cited: 22 February 2011.] http://www.w3.org/TR/geolocation-API/.

18. Gruber, Frank. Comparing the Mapping Services. TestCrunch. [Online] 17 April 2006. [Cited: 20 February 2011.] http://techcrunch.com/2006/04/17/comparing-the-mapping-services/.

19. Google. The Google Geocoding API. Google Code. [Online] [Cited: 22 February 2011.] http://groups.google.com/group/Google-Maps-API/msg/ac4ed8f8063347cc states limit is 50,000 geo requests?.

20. Yahoo. Yahoo! Maps Web Services . Yahoo Developer Network. [Online] [Cited: 22 February 2011.] http://developer.yahoo.com/maps/rest/V1/geocode.html.

21. Microsoft. Bing Maps Licensing. Microsoft. [Online] [Cited: 22 February 2011.] http://www.microsoft.com/maps/product/licensing.aspx.

22. Google. Google Maps API Premier. Google Code. [Online] [Cited: 22 February 2011.] http://code.google.com/apis/maps/documentation/premier/faq.html#pageview.

23. Support, Carlos Google. Help forum . Google Maps. [Online] [Cited: 22 February 2011.] http://www.google.com/support/forum/p/maps/thread?tid=42dbb1b2b5dbc6ad&hl=en.

24. Access 2007 specifications. Microsoft. [Online] [Cited: 26 February 2011.] http://office.microsoft.com/en-us/access-help/access-2007-specifications-HA010030739.aspx.

25. When to migrate from microsoft access to micosoft SQL server. Microsoft. [Online] [Cited: 7 March 2011.] http://www.google.co.uk/url?sa=t&source=web&cd=6&sqi=2&ved=0CD4QFjAF&url=http%3A%2F%2Fdownload.microsoft.com%2Fdownload%2F5%2Fd%2F0%2F5d026b60-e4be-42fc-a250-2d75c49172bc%2Fwhen_to_migrate_from_access.doc&rct=j&q=150%20simultaneous%20connections%20microso.

26. Ruderman, Jesse. Same origin policy for JavaScript. Mozilla Developer Network. [Online] [Cited: 27 February 2011.] https://developer.mozilla.org/en/Same_origin_policy_for_JavaScript.

27. Ricket, Doug. Market Manager. You Tube. [Online] [Cited: 09 10 2010.] http://www.youtube.com/watch_popup?v=0wmfBiGv1t8&vq=small#t=79.

28. How to prevent caching in Internet Explorer. Microsoft Help and Support . [Online] [Cited: 27 February 2011.] http://support.microsoft.com/kb/234067.

Appendix

Project Gantt Chart

Screen Shot: Initial Screen on Web application

This is the initial webpage on the web application which allows the user to enter their location and destination. The website accepts postcodes or address. The website uses this information to calculate the most suitable bus stops and bus number.

Bus Stop Selection & View mode

This is the second web page of the web application which allows the user to select one of the three nearest local / destination bus stops. This page also allows the user to choose whether they want the information to be displayed in a graphical, tabular or graphical and tabular format, as requested by the questionnaire results.

Graphical and Tabular View

This webpage shows the graphical map with icons of the local / destination bus stops. The bus markers will move with respect to the buses real time position. This page also shows the tabular data which consists of useful information such as the bus number, and street names of the bus stops.

Embedded Target Program Flow Chart

Web Server Script Flow Chart

Web Browser Compatibility Tests

Browser	Forms	Ajax	Google API	Database	XMLHttpRequest	Haversine algorithm	GUID	DIV tags	Markers display	Bus Marker updates	Tabular data updates
Internet Explorer 6*	NO	YES	YES	YES	NO	YES	YES	NO	NO	NO	NO
Internet Explorer 7	YES	YES	YES	YES	YES	YES	YES	YES	YES	YES	YES
Internet Explorer 8	YES	YES	YES	YES	YES	YES	YES	YES	YES	YES	YES
Internet Explorer 9	YES	YES	YES	YES	YES	YES	YES	YES	YES	YES	YES
Chrome 9	YES	YES	YES	YES	YES	YES	YES	YES	YES	YES	YES
Firefox	YES	YES	YES	YES	YES	YES	YES	YES	YES	YES	YES
Opera	YES	YES	YES	YES	YES	YES	YES	YES	YES	YES	YES
Safari	YES	YES	YES	YES	YES	YES	YES	YES	YES	YES	YES

* Internet explorer 6 does not support XMLHttpRequest natively.

Web Application Display Resolution Compatibility Tests

Screen resolutions	Acceptable
640×480	YES
800×600	YES
1024×768	YES
1600×1200	YES
320×480	YES

Hierarchy of Client Side Application

Hierarchy of Server Side Application

Despite the name asynchronous javascript, requests do not need to be asynchronous ↑
Despite the name asynchronous javascript, requests do not need to be asynchronous ↑
JavaScript Object Notation (JSON) would also be acceptable ↑
A work around is to split the database by pointing a front end database to potentially thousands of backend databases. ↑

GPS Bus Tracking System