ELEC 399 Progress Report #2
By: Dana Leslie, Doug Maclean and Harland Sims
Supervisor: Fayez Gebali, Kin Fun Li & Michael McGuire
Group: #1
Due: July 6, 2012
Dept. Electrical and Computer Engineering
University of Victoria
All rights reserved. This report may not be reproduced in whole or in part, by photocopy or other
means, without the permission of the author.
ELEC 399 Progress Report #2
ii
Table of Contents
Chapter 1: Project Overview ........................................................................................................... 1 Team Biographies ....................................................................................................................... 3
Dana Leslie ............................................................................................................................. 3 Doug Maclean ......................................................................................................................... 4
Harland Sims ........................................................................................................................... 5 Chapter 2: Progress Review ............................................................................................................ 6
Technology Research .................................................................................................................. 6 Bluetooth ................................................................................................................................. 6 Wi-Fi ....................................................................................................................................... 7
GPS Technology Overview .................................................................................................... 8 Wireless Broadband ................................................................................................................ 9
Near Field Communication ................................................................................................... 10
Quick Response (QR) Code .................................................................................................. 11 Feature List ............................................................................................................................... 12 Implementation Options............................................................................................................ 12
Implementation 1 .................................................................................................................. 13 Implementation 2 .................................................................................................................. 14
Implementation 3 .................................................................................................................. 15 Implementation 4 .................................................................................................................. 16 Hardware Utilization Comparison ........................................................................................ 17
Chapter 3: Text Review (Parts 2 and 3) ........................................................................................ 18 Conclusion .................................................................................................................................... 20
References ..................................................................................................................................... 21 Appendix A – GSM Coverage Maps ............................................................................................ 22
Comments by the supervisor:........................................................................................................ 25
1
ELEC 399 Progress Report #2
Chapter 1: Project Overview
Project Title:
Design of a Smart Bus Stop Supervisor:
Fayez Gebali, Kin F. Li & Michael McGuire
Motivation/Background Currently, visually impaired people face many challenges when attempting to utilize the public
transit system in the Victoria region. The challenges they face include getting to the appropriate
bus stop, being informed of the predefined bus schedule, ensuring they board the correct bus and
knowing when to exit the bus. These challenges could all be overcome through the utilization of
existing technologies such as GPS, wireless communication protocols and smart phone
application development. Another research group at UVIC has been working on the development of a smart phone
application that guides the visually impaired user from a start point to an appropriate bus stop.
Additionally Blackberry has done development into notifying the user, once on the bus, when
they are to disembark. This work would greatly benefit our project as it addresses a large portion
of the goals of the smart bus stop project. One major problem that is not addressed, however, is
that the predefined bus schedule may not always reflect the true order of bus arrival. If a bus is
late or early, the person may end up boarding the wrong bus, or be required to ask the driver for
confirmation. Additionally, Professor Gebali has expressed interest in implementing a system
that would notify the driver that a visually impaired user is at the next stop and is intending to
board. This would benefit the user as the driver could then take the necessary steps to ensure that
the user boards the correct bus in a safe manner.
This project can be thought of as a small, specialized portion of the larger proposed ELEC
399/499 project titled “Smart Campus Design and Development”. If the final implementation is
compatible, the technologies and topologies used may be applicable to utilization with other
areas of that initiative. Project Direction In our preliminary discussions surrounding project implementation, we considered multiple
options for dynamically being able to track bus locations. The first and most obvious was to
equip all buses in service with a GPS and a communication module. The location data of all
buses could be sent back to a main server, and when a user checks in at a bus stop, the server
ELEC 399 Progress Report #2
2
could push the relevant information to the user. This information could be pushed through an app
running on a smart phone and possibly be integrated into the same application that was used to
direct the user to the bus stop. This option would yield the most accurate real time information
when tracking bus locations, but also could be effected by bad weather and high operation costs. The second option was an alternative to equipping each bus with a GPS module, and entailed
having a network of Bluetooth modules attached to the stops and the buses. This would allow
each stop to be able to detect when a bus arrives, and make predictions based on distance as to
the time it will take to reach the next stop. This option would require that the stops be able to
communicate with some sort of central server, or to have centralized communication hubs and
have surrounding stops daisy chain off each other to achieve communication with the central
server. Other dynamic bus tracking options were discussed and all have their own associated pros and
cons, but in the end, our decision will be based on the optimization of economic and
technological feasibility, weather and social constraints, and the needs of the Victoria Transit
authority. Work Plan: The plan to complete this project consists of a couple major parts. Initially the brainstorming of
features and research into technologies that could be used to attain these features is necessary,
followed by the comparison of various technologies and different implementations. Firstly, a list of required features is to be devised. This would a list of the very essential areas
that would need to be addressed in order to allow a visually impaired user at a bus stop to clearly
know which bus to enter. A list of additional, nonessential, features is to be devised concurrently.
This list will consist of extra features perhaps to add efficiency, ease-of-use, or to appeal to a
more general user base. Together this step will constitute the creation of a system specification
(both essential and secondary). Next would be a comparison of technologies that can perform some or all of the features. This
will consist mainly of the technologies currently available on most smart phones: Bluetooth, Wi-
Fi, data connection (ex. 3G or 4G) and GPS, but could also lead to research into electronics for
implementation of devices on the bus or at the stop. Areas that will be looked into for an
implementation will include features, cost, ease-of-use and how much work it would take to
implement a final product. At some point, BC Transit should also be contacted in regards to their
openness in creating a smarter, more accessible transit system, what types of technologies they
may or may not be willing to have installed on buses or at stops, and if they would be willing to
fund any kind of modernization of the bus stops and general system. Once enough implementations are considered and one is well reasoned and chosen, further
research is to be done into the hardware needs of the implementation. The hardware should be
designed, simulated and a parts list including pricing should be completed.
ELEC 399 Progress Report #2
3
Milestones:
Please see Deliverables section, below, for milestone details pertaining to prescribed deliverable
deadlines. In addition to the milestones listed there, one additional goal or milestone has been
formulated:
- Complete research into possible implementations, make a decision on which
implementation to pursue, and complete designs/simulations/price lists of the
hardware required (to be done in time for Final Report and Presentations)
Due Date: July 31st
Deliverables:
- Poster Presentation & Demo Due Date: July 31st
- Web Presentation Due Date: August 3rd
- Final Report Due Date: August 3rd
Team Biographies
Please note that the following biographies appear in alphabetical order, and that no set
designations or group roles have yet been affirmed.
Dana Leslie
One of the three members of the “Design of a Smart Bus Stop” group is Dana Leslie. Dana is a
fourth year Electrical Engineering student who is planning on completing the Digital and
Embedded Systems and Electronics program specializations. Dana utilizes the public transit
systems in the CRD (Capital Regional District) to commute to and from school, and has a
firsthand understanding of how a smart bus stop system could not only benefit visually impaired
people, but also the general populous.
In his spare time over the past four years, Dana has utilized the Arduino microcontroller &
development board to create a variety of projects. One noteworthy project that Dana has worked
on was an Arduino based GPS logger that stored GPS data onto a MicroSD card. The initial
inspiration for this project was to build a device that could be used for Geo-Caching, but one can
easily see how this technology could be used in other applications such as fleet tracking or even
the smart bus stop project.
ELEC 399 Progress Report #2
4
The initial prototype of the Geo-Caching device was successfully able to take raw NMEA data
and parse it into human readable data containing longitude, latitude and time. This step required
that the Arduino be able to capture the serial data being output by the GPS module. This data
stream was in the form of raw NMEA data. These strings were then parsed by the Arduino and
the relevant information was extracted and saved in a CSV (comma separated value) file on the
MicroSD card. The MicroSD card could then be plugged into a computer where the CSV file
could be read in a program such as Microsoft Excel. The future plans for this project are to attach
an LCD display so that the positional data could be displayed in the field instead of just being
stored. Additional functionality could include a bearing calculator that displays a compass
bearing instead of having to compare current Geo-position with desired Geo-position.
Dana’s work with GPS based technologies has granted him deeper insight into the abilities and
constraints of modern day GPS technology. Other than an understanding of mobile
communications, the major challenge in the smart bus stop project is dynamically being able to
track the location of the Victoria Transit fleet (or otherwise make intelligent guesses as to a buses
arrival time). Although GPS is not the only solution that could achieve this goal, Dana’s
firsthand knowledge of the technology will be of benefit to our group when considering the
possible options.
Doug Maclean
Doug Maclean is an electrical engineering student in the first term of his fourth year and he has
an interest in both the power systems and communications specializations. For first year he
attended Vancouver Island University after which he transferred to the University of Victoria;
throughout his time at University he has had strong grades, most prominently in the lab portions
of classes.
Doug’s first co-op was an IT support position at Canada Revenue Agency in which he learned a
great deal about large computer network administration and the troubleshooting of daily
computer issues. Recently, Doug finished a co-op term at Capital Region Emergency Services
Telecommunication Inc. which operates and administers the trunking radio infrastructure for the
police, ambulance, and fire agencies, among others, in the Capital Region and Southern Gulf
Islands. During that term he learned a great deal about several different communications
protocols and technologies, as well as different practical network topologies. One project
included configuring an IP multiplexer and Microwave link for a remote dispatch center, the
work gave a good insight into this particular technology, and its other possible applications; this
was an alternative to a T1 leased line which is the usual standard. Additionally, much of the
other work involved the troubleshooting of issues at various VHF radio transceiver sites and
surveying CREST’s system coverage using a geographic signal assessment program running on a
laptop, a VHF test set and receiver, and a GPS receiver to log and analyze signal data. This led to
an insight into GPS logger technologies.
In Doug’s spare time, he has worked on a sun tracking solar cell project. He has done work on
some mock-ups using an Arduino micro-controller and servo as well as some design into a less
sophisticated low power electronic (ICs) circuits. The end goal of this project is to increase the
ELEC 399 Progress Report #2
5
efficiency of the solar panel at his father’s cabin for a low cost. Solar power could be a cost
effective way to power any possible electronics needed at the bus stops.
Doug’s experience with telecommunications, network topology and electronic design would be
an asset to the Smart Bus Stop project. He has had experience using various communications
standards and has a valuable insight into that area as well as design of the possible necessary
electronics and their power systems.
Harland Sims
Harland (or Harley) is an electrical engineering student currently in the 4A academic term.
Deciding to enrol at the University of Victoria in engineering straight from high school, he
effectively leveraged a long-standing interest in computer hardware and electronics, as well as
strong academic skills, into a thus-far successful university career.
His first two co-op work terms were in the enterprise IT field at Victoria-based GIS company
Latitude Geographics. These co-ops gave him knowledge of server hardware and administration
as well as system planning and interconnection. Notably, during his second work term, he
planned and implemented an office-wide wireless system, from specification through to final
deployment. This system used open-source firmware on consumer-level hardware to implement
features normally available only on much more expensive, specialized hardware. He also
programmed several small web applications in C++ throughout these terms, which were rolled
out for employee use. All of these skills may be helpful during this project.
More recently, he completed a four month co-op term at PMC-Sierra in Burnaby, B.C., where he
worked in their Product Engineering department. Working as a part of a characterization effort
for an upcoming RAID-related device, Harley gained proficiency in test automation and
scripting and the use of laboratory testing equipment to characterize semiconductor devices, as
well as learned effective time management to meet deliverable deadlines. Should this project be
continued through to an implementation stage, Harley’s knowledge of electronics testing and
verification will be helpful in ensuring a working system.
In his remaining time at UVic, Harley hopes to receive a specialization in Digital & Embedded
Systems, as well as study more about electronics, communication and various engineering
techniques. As a frequent bus user, he also brings first-hand knowledge of the problems which
can be faced while using public transit, and has a strong desire to see the world improved via the
intelligent application of technology.
ELEC 399 Progress Report #2
6
Chapter 2: Progress Review
Technology Research
The following sections relate to some of the technologies researched for use in the smart bus stop
application. A main consideration is allowing the bus stop to be widely interoperable with most
smartphones. As such the main areas of research were into: Bluetooth, Wi-Fi, GPS, and wireless
broadband (e.g. 3G data) additionally Quick Response (QR) codes and Near Field
Communication (NFC) were considered.
Bluetooth
Bluetooth is a wireless communications standard most commonly used to enable hassle-free
communication between small devices such as mobile phones and their accessories. Its intended
purpose is to facilitate easy communication between small ad-hoc networks of devices, termed
piconets. Bluetooth is an ideal candidate technology because it has become ubiquitous in modern
mobile phones, allowing nearly universal compatibility.
Bluetooth operates on the Industrial, Scientific & Medical (ISM) frequency band, specifically in
the range of 2402 to 2480 MHz. Radio modules are separated into 3 classes, based on their
power output and therefore their range. Class 3 modules are extremely low power, outputting a
maximum of 1 mW and having an operating range of around one meter. For the purposes of this
project, the most relevant classes are 1 and 2. The Bluetooth radios found in cellular phones are
Class 2, having a maximum power output of 2.5 mW and an approximate operating range of 10
meters. Class 1 modules are much higher powered, outputting up to 100 mW and a
communicating over a range of up to 100 meters. Thus depending on the desired range, a
Bluetooth-enabled bus stop would be able to push relevant information out to mobile users at
either 10 or 100 meters (range estimations are approximate and can be affected by weather
conditions, etc.). Bluetooth radio modules are compact and can be purchased extremely cheaply
due to the technology’s maturity, making it an ideal communications protocol for low-cost, high-
volume applications like a bus stop network.
Bluetooth piconets operate using a master / slave topology, with one master being able to
communicate with up to 7 slave devices simultaneously. Many more devices (up to 255) can be
kept connected to the piconet in an inactive state, with the connections able to be reactivated
easily. This would allow a Bluetooth enabled bus stop to push route and timing information out
to up to 7 users simultaneously, with larger numbers of users handled via rotation of active and
inactive devices (constant two-way communication would not be required). The data rates the
standard is capable of have increased from an original limit of 1 megabit/second up to 2.1/3
megabits/second with protocol upgrades. However, bus route and timing information is not
predicted to be bandwidth intensive, and thus the lowest data rate would suffice (this would
ELEC 399 Progress Report #2
7
allow the greatest amount of backwards compatibility with older Bluetooth-enabled devices, as
well).
Upon initial discovery of a connectable device, the Bluetooth protocol allows a device to quickly
communicate what services it can offer through the sharing of a list of compatible Bluetooth
profiles. These profiles are specific, standardized configurations for sharing or transmitting
certain types of data. Thus a Bluetooth-enabled bus stop would broadcast compatibility with the
only the relevant profiles— basic file transfer, etc. Bluetooth’s ubiquity, compatibility and low
hardware pricing makes it an extremely good candidate to be used for short-range bus stop to
end-user communication.
Wi-Fi
Wi-Fi is a popular brand of wireless area networking technology based on the IEEE 802.11
standards. Its purpose is mainly to facilitate Wireless Local Area Networks (WLAN) using the
unlicensed 2.4GHz ISM band. 802.11 has had several generations of amendments since the
original standard, however it is still largely the same basic protocol. The most common versions
are currently 802.11b and 802.11g, however 802.11n is gaining popularity as it allows a higher
data rate and range through the use of parallel streams and requiring multiple antennas.
The data rate able to be attained using b varies from 1 to 11 Mbit/s and has a range between 38m
and 140m; g has about the same range however it can attain a higher data rate (6 to 54 Mbit/s)
using a different modulation scheme. Wireless n is able to achieve a higher data rate and range
(70m to 250m) due to its multiple-input multiple-out antennas (up to 150Mbit/s). However, due
to the popularity of the ISM band in which Wi-Fi operates, there is a large amount of inherent
noise and channel overlap limiting the usable range of this technology with a reasonable power
supply (limited by regulations).
The 802.11 has two basic modes of operation: peer-to-peer mode and infrastructure mode. In
infrastructure mode, mobile units communicate through an access point to a central point, often a
router or a computer network. Peer-to-peer mode enables Wi-Fi enabled devices to communicate
directly. Wi-Fi also includes shared-key encryption mechanisms: Wired Equivalent
Privacy (WEP), Wi-Fi Protected Access (WPA, WPA2), offering a higher security level than that
of Bluetooth.
Wi-Fi modules are available at comparable prices to Bluetooth modules and offer higher
functionality, data-rates, effective range and security; however due these advantages they
generally require a great deal more power to operate: at least 0.5W for the module alone. As such
Wi-Fi is not being immediately considered in the implementation, however it may be
reconsidered after research is put into the capabilities of possible power systems.
One such module can be found here:
http://www.embdsocial.net/about/#wisp
ELEC 399 Progress Report #2
8
GPS Technology Overview
The “Global Positioning System” is a satellite network in orbit about the Earth that was
implemented by the U.S. Department of Defence in the 1970’s. It consists of 24 satellites that are
all equipped with an extremely precise atomic clock, and they are all aware of their own position
in space at all times. Each satellite continually emits a high frequency signal that is modulated to
contain information about that satellites current position, and time the message was sent. This
message propagates through the Earth’s atmosphere at the speed of light where it can be received
by a GPS module.
The GPS module is capable of detecting the signals of many GPS satellites, as all that is required
is a direct line of sight. The GPS satellite network orbits in such a way that at any point on the
Earth’s surface, there should be at least 6 satellites visible. In order to accurately predict its
global position, the GPS module must have a “lock” on at least 4 GPS satellites. It then uses the
time and position data it’s acquired, along with basic trilateration and physics principals, to
determine its position on the Earth.
Range:
A GPS module can predict its position from any location on the Earth, providing it has a clean
line of sight to at least 4 GPS satellites. For our application, it may be important to consider the
mounting location of the GPS module as the signal can propagate through plastic and glass, but
not the metal sheeting on the exterior of a vehicle. Some GPS modules allow for external
antennas which could be mounted on the outside of the vehicle. Additionally, buildings inhibit
the reception of GPS signals and there may be occasional dead zones in metropolitan areas with
tall buildings. Given the nature of the Victoria landscape and the application of public transit,
dead zones due to buildings would most likely not pose issues that would affect the overall goals
of the project.
Cost:
The cost of the GPS module its self is the only cost associated with utilizing GPS technology.
There is no recurring utility fee associated with GPS, and as such, the only fee aside from the
initial purchase of the module, would be replacing a broken one. The GPS modules on SparkFun
range in price from 40 to 100 dollars when bought in single unit quantities. The low end of the
price range pertains to SMD chips that would require a custom designed circuit to interface with
our system processor. The middle of the price range pertains to GPS modules that require only
power, ground and a couple of I/O lines. These modules do use specialized connectors however
and would require minimal circuitry when connecting them to our system.
http://www.sparkfun.com/products/11058
http://www.sparkfun.com/products/464
The previous links depicts a GPS module and antenna that could be utilized by the majority of
processing units. The above combination would cost 65 dollars per bus being tracked. As stated
previously, all that would be required to interface this module with a processing unit would be
power, ground and serial data connection lines.
ELEC 399 Progress Report #2
9
Processing:
The vast majority of GPS modules output raw NMEA data over their serial communication lines.
These NMEA strings are not human readable but contain positional information such as
longitude, latitude and altitude. When extracting this positional information, external data
processing is required to parse the strings and extract the desired data. This string parsing is not
CPU intensive and can be performed by the processors found in most modern embedded
systems.
Wireless Broadband
3G communication is a means of transferring data via the already established cellular networks.
Cellular modules can be purchased and interfaced with a microcontroller allowing data
connectivity for a mobile entity such as a public transit bus or a non-wired bus stop. However
additional and somewhat significant service fees will be required for this option. An attempt has
been made to get a quote for something of this scale however there has been no response as of
yet.
Hardware Details:
One provider of cellular communication modules is Sparkfun. Although other electronics
suppliers such as Digikey may offer similar products at lesser cost, Sparkfun supplies extensive
documentation which allows us to see how these modules would be interfaced with other
hardware. The two GSM cellular modules that Sparkfun carries are 50 and 60 dollars. They both
have proprietary I/O connectors and would require an external antenna to be attached.
http://www.sparkfun.com/products/9533
http://www.sparkfun.com/products/10138
Depending on the application, they will also require external circuitry in order to be interfaced
with our processor. For both the modules listed above, Sparkfun offers a “breakout board” which
utilized the proprietary connector to break out the I/O lines for easier use. For one of the two
modules listed above, the SIM card is attached to the GSM module, and for the other it is
attached to the breakout board:
http://www.sparkfun.com/products/9427
http://www.sparkfun.com/products/10741
Lastly, an Arduino shield is available for the SM5100B unit which would make interfacing the
two devices trivial, assuming we choose the Arduino for our processing option. This shield is
open source and may be beneficial in determining how the GSM module would interface to other
processors.
ELEC 399 Progress Report #2
10
For both of the options listed above, an antenna will be required at minimal cost:
http://www.sparkfun.com/products/675
http://www.sparkfun.com/products/9145
Based on the documented use of the two modules listed above, they can be interfaced with Atmel
microcontrollers and most of the common competitors, PIC, ARM etc. The total cost for a GSM
module, antenna and interfacing circuitry would be approximately 80 dollars when bought in
single unit quantities (full-scale implementation would obviously involve bulk purchases at a
discounted rate).
Applications: Both of the modules listed above are capable of typical cellular communication methods such as
SMS, TCP/IP and GSM. These methods could be utilized when dynamically monitoring fleet
vehicle location when paired with a GPS module. Cellular triangulation may also be an
interesting option to look into as it may eliminate the need for costly GPS hardware. One article
referencing a different Arduino cellular shield implied the Arduino was capable of cellular
triangulation (please see reference section for article).
Environmental limitations for cellular communication are very limited when considering the
scope of the project. Weather does not limit their effectiveness and street level outdoor usage in
an urban environment is viable. Two major cellular service providers list their coverage maps as
encompassing the entirety of the CRD (Appendix A).
Near Field Communication
Near field communications (or NFC) is an emerging wireless communication technology that
aims to provide extremely simple and intuitive short-range communication. It operates over the
shortest range of any profiled technology; NFC transfers generally happen in the range of 4 or
less centimetres. This limited range, naturally, means that NFC power consumption is very low
(15 mW to receive from an active device, for instance). In addition, NFC can be used to
wirelessly power and receive data from passive, unpowered devices. This means that NFC
technology can be integrated into a huge variety of everyday objects through the use of NFC-
capable tags or decals.
Taking much of its base from existing RFID (radio-frequency identification) technology, NFC
has been standardized by the ISO and IEC. It is beginning to become more common in cell
phone hardware, though the technology is still young and adoption is not yet widespread.
Implementation of a large network of NFC-enabled bus stops hinge on larger-scale adoption of
the technology (as requiring users of the system to have certain cell phones is seen as an
impediment to maximizing usefulness for the end user). Data rates vary from 106 kilobits/second
up to 424 kilobits/second, much lower than many other technology protocols, but bus stop
communication is not expected to be data intensive, thus this limitation is not critical. The range
ELEC 399 Progress Report #2
11
limitation, however, is quite critical, as a visually-impaired patron cannot be expected to position
their cell phone within 4 centimetres of the bus stop transmitter device.
For these reasons, NFC is not considered to be of practical use for the main communications
channels of this project.
Quick Response (QR) Code
Quick Response (or QR) codes are a standardized form of two-dimensional barcode. They have
recently begun to gain popularity, due largely to the increasing ubiquity of smart phones, which
are capable of reading and decoding them. A QR code is a large rectangle composed of smaller,
either black-or-white pixel-like rectangles. Standardized under ISO/IEC 18004:2006, parts of the
code are reserved for pattern recognition and alignment aids, as well as structures which convey
version and formatting information. QR codes can be used to encode plain text, URLs or many
other types of data (including application specific data).
QR codes are at their most useful when used to transmit information that is not easily written
down or easily remembered—long or easily-misspelled website URLs, for example. A bus stop
with smart phone connectivity could quite easily incorporate a QR code decal on its sign which,
when scanned, takes the user to a website allowing download of the bus system application.
Also, QR codes could be devised which transmit information this application—bus stop IDs,
notices of schedule updates or modifications, etc. Even basic settings for a Bluetooth or Wi-Fi
connection pairing could conceivably be encoded into a code. QR codes are an easily
implementable and low-budget way to help facilitate communication, though their usefulness in
direct relation to visually-impaired persons is quite limited. Current QR code scanning
applications require the device to be held quite close to the code, as well as being kept steady for
a sufficient amount of time. For this reason, QR codes are considered to be an easily
implementable add-on (which would add functionality for regular users), but not a core
technology requirement.
ELEC 399 Progress Report #2
12
Feature List
Required Features Secondary Features
Up-to-date bus scheduling information
specific to given stop
User notification of bus information (via
audio)
Bus driver notification of visually impaired
user waiting
Dynamic (semi-)real-time bus tracking
Sophisticated on-bus cue of disabled transit
user
Trip planner
Implementation Options
When considering the implementation of a “Smart Bus Stop” initiative there are two major goals
our project aims to address: Firstly, our solution must convey bus schedule information to a
visually impaired user. And secondly, the bus driver must be notified that there is a visually
impaired rider attempting to board the bus. Both of these goals can be achieved in many ways
and as such, our group has developed 4 theoretical implementation scenarios that address our
goals.
Establishing a communication dialogue with BC Transit is a high priority going forward for this
project. Information regarding their plans for the future, what technologies they have done
research into, what technologies they may be in favour or against implementing, etc. would be
invaluable in making informed implementation decisions. Basic infrastructure questions that will
arise with regards to implementation and cost estimation could also be easily answered by BC
Transit (questions such as how many stops are currently serviced, how many buses are active in
a given day, etc.). Two attempts at communicating with BC Transit have been made thus far. Both times voicemail
messages were left with different employees, most recently with David Guthrie, the Victoria
Regional Transit Director of Operations. We are hopeful that a dialogue can be established at
some point in the near future. And as such, no definitive decision on the following
implementations has been made.
ELEC 399 Progress Report #2
13
Implementation 1
Our first implementation utilizes blue tooth communication channels between all three entities,
the rider, the stop, and the bus. A typical usage scenario would start with the rider arriving at the
bus stop and checking-in via a smart phone application. The bus stop would push a unique
identifier to the application on the user’s phone which would then vocalize relevant schedule
information. The bus stop would also start broadcasting a signal to the bus as soon as it’s within
range and a signal light on the bus would notify the driver that a visually impaired user is
attempting to board the bus.
ELEC 399 Progress Report #2
14
Implementation 2
Our second implementation utilizes far more advanced technologies and as such, would have
more functional capabilities than implementation 1. In this implementation, all buses would be
outfitted with a 3G communication module, and a GPS. This would be paired with a backend
server that is constantly aware of the location of all buses in the fleet. A typical usage scenario
would start again, with the rider checking in at the bus stop. This would be achieved by the GPS
on the user’s smart phone pushing its current location to the application which would then
determine the closest bus stop. Once the specific stop was identified, the schedule information
would be vocalized through the user’s smart phone. The application would also send a flag to the
driver that there is a visually impaired patron waiting to board the bus.
ELEC 399 Progress Report #2
15
Implementation 3
In this implementation all bus stops would be outfitted with a 3G communication module and a
blue tooth device. The bus would also be outfitted with a blue tooth module. A typical usage
scenario would start with the GPS module on the user’s phone identifying the user’s current
location. The user’s location would be pushed to a server back end via 3G. The user’s phone
would vocalize schedule information and the stop would be alerted that a visually impaired rider
is attempting to board the bus. As the bus approaches the stop, it alerts the driver by means of an
onboard LED indicator.
ELEC 399 Progress Report #2
16
Implementation 4
The last and most feasible implementation idea requires that there be no hardware added to the
bus. In this scenario, the bus stop would be outfitted with blue tooth, and a light that would serve
as a visual indicator to the bus driver. A typical usage scenario would start with the smart phone
checking-in to the stop via blue tooth. The stop would push a unique identifier to the application
which would vocalize schedule information. Upon check-in the stop would also illuminate the
LED indicator so that the approaching driver can see that there is a visually impaired rider
attempting to board the bus.
ELEC 399 Progress Report #2
17
Hardware Utilization Comparison
The following table outlines the estimated hardware requirements for each of the four
implementations. This estimation assumes that the smart phone being used is blue tooth and 3G
equipped.
Implementation
Number
Number of Blue
Tooth Modules
Number of
3G Modules
Number of
Microcontrollers
Number of
GPS Modules
1 2 0 2 0
2 0 1 1 1
3 2 1 2 0
4 1 0 1 0
As you can see from the previous table, implementation 4 utilizes the least amount of each of the
4 hardware components. Implementation 4 accomplishes the two main objectives of the smart
bus stop project but does lack some functionality that is offered in other implementations. For
example, in implementation 2, we are able to monitor real time fleet location information which
could be beneficial if there is a delay due to breakdown, traffic or scheduling error. The other
two implementations also offer some functionality that is not offered in number 4 but the utility
costs and initial hardware investment is greater than for number 1. Further research will be
conducted to identify the needs of the CRD transit authority and whether the added functionality
would benefit visually impaired users greatly enough to warrant the additional cost.
ELEC 399 Progress Report #2
18
Chapter 3: Text Review (Parts 2 and 3)
Continuing from where Part 1 left off, Parts 2 and 3 of Systems Analysis and Design, 5th Edition
focus on the next several major steps of the system development life cycle. Part 2 is primarily
concerned with the Analysis Phase, which involves answering some of the main questions about
the new system: Who will use the system? What will the system do? Where and when will the
system be needed? After the Analysis Phase comes the Design Phase, the subject of Part 3. The
Design Phase covers decisions about how the system will operate, as well as generation of a
detailed system specification.
The first stage of Analysis is outlined in Chapter 3, the process of requirements definition. This
begins by gathering a list of high-level business requirements for the system, possibly through a
combination of different elicitation techniques (interviews, questionnaires, document analysis,
observation and joint application development are all pointed out as useful techniques). At this
early stage, these business requirements can be thought of as what the system is required to do.
Analysis then takes place to begin refining them into a list of more concrete system
requirements. Next, the process of use case analysis is undertaken (the main subject of Chapter
4). Use cases are a necessary part of the system process model and as such their formulation is
important analysis step. Creating a possible use case begins with identifying the triggering event
and the primary actor. Next, a list of steps involved in moving from inputs to desired outputs is
developed, and each step and its specific I/O actions are elaborated upon. A repository of all use
cases which can be thought of is created and refined.
Utilizing the use cases as a guiding tool, the process modelling procedure begins. During this
step, all system processes (an activity that does something) are described using a special diagram
called a data flow diagram (or DFD). These DFDs are created directly from the use cases, and
allow a modular, process-driving view of the system to be built. The DFD description use a
specific set of syntax and symbols. Chapter 5 describes in detail the process of creating these
DFDs and the syntax to utilize in doing so. The next step in creating a more coherent system
view is the creation of an entity relationship model. This is a data-based model of the system,
consisting of entities (an item about which data is to be collected), attributes (which are pieces of
information belonging to entities) and relationships, which help track association between
entities. After the entity relationship diagram has been formulated, it is validated through a
process wherein series’ of logical rules are applied in an effort to streamline the model. Chapter
6 covers the entity relationship diagram formulation and validation process.
This marks the end of the Analysis Phase, and thus of Part 2 of the textbook. Part 3 covers the
Design Phase of the SDLC, the phase in which decisions about how the system will actually
operate are made. At the conclusion of the Design Phase, a complete and detailed system
specification is available to begin system implementation. The first portion of design, however,
is taking the system requirements as refined in the analysis phase and utilizing them as primary
inputs into your design process. Early on a decision should be made regarding which of the three
system acquisition strategies is to be used: developing a custom application in-house, buying a
packaged system from a third-party and customizing it, or hiring an external company to both
build and support the system. Of the three, custom in-house development is the most flexible,
ELEC 399 Progress Report #2
19
and also allows for gains in technical knowledge to stay within your organization. However,
unless this expertise is already present in the organization, it can be more efficient to purchase a
ready-made program or package. Leveraging the expertise of an external developer can be a
great option, but does necessitate some loss of control over your potentially confidential data, as
well as leaving you with less control over future development of the system. Another large
decision to be made is a choice of computing architectures: options such as server-based, client-
based, client-server mixed architecture, as well as recent additions like cloud-based architecture
all provide a unique set of advantages and disadvantages. Architecture design decisions
culminate in a detailed list of hardware and software specifications, which is key to refining price
estimates for system implementation.
Also important during the Design Phase is specifying the desired user interface for the system.
Interface design is driven largely by the data flow diagrams created in the analysis phase, and
also takes into account common use cases and the expected skill level of the end user. The
overall design philosophy is guided by several basic design goals: make navigation of the
application as simple as possible, make inputting accurate data into the system as easy as
possible, and present relevant information to the user via the least effort possible on their part.
Interface prototypes and user scenarios are used in this stage to help solidify interface design
specifications.
Next is what is termed Program Design. This stage involves translating the logic-based process
model from the Analysis Phase into a more physical-driven new process model. This new model
will include implementation details, human actions, physical transfer media necessary during
each step, etc. As with most of these specialized models, there is specific syntax which is used to
construct this model, and guidelines to follow to correctly structure the model. The end result is a
hierarchically-arranged chart which conveys system structure, control modules, data flow paths
and implementation details. Program specifications can be elaborated on even more, however.
This can be as detailed as actually creating pseudo-code representations of some processes.
The last portion of the Design Phase is the design of the data storage sub-system. To begin this
process, data necessary for system operation is broken into two categories: files and databases.
Within these categories, there are five types of files and four types of databases. These database
types are: legacy (these are older, outdated databases which the new system may need to be
interfaced with), relational (this is the most popular database type, based on collections of
tables), object (which contain object classes, and are common in multimedia applications) and
multidimensional (which store large numbers of pre-calculated quantitative information).
Selecting the proper database type for the system and being aware of what types of databases it
may need to interact with externally is key to data storage design success. Since different types
of databases are more suited to storing data of certain types (and with certain use scenarios),
choosing the proper database type can greatly improve overall system performance.
ELEC 399 Progress Report #2
20
Conclusion
The ELEC 399 project, Design of a Smart Bus Stop, poses an interesting and challenging design
problem with the potential to significantly change the way visually-impaired individuals use
public transit. The motivation behind the project idea stems from previous work conducted by
the project’s co-supervisors to empower visually-impaired individuals in getting from a location
to a bus stop through the use of a specialized smart phone application. This project aims to
bridge the next gap present in this transportation chain—getting the individual from the bus stop
safely onto the bus he or she wishes to take.
Research has been done into the possible communication protocols which could be used to
determine a variety of project implementations. A few possible implementations were outlined;
these implementation ideas are to be gauged against real-world constraints (such as economic
and technical feasibility, ease of implementation, geographic and social concerns, etc), ideally
with some input from BC Transit. Moving forward, focus will be placed on deciding on an
implementation and completing a viable design using a minimal amount of power and
determining a parts/costs list.
Finally, Parts 2 and 3 of the course textbook (Systems Analysis and Design) were read and
summarized. This portion of the text focused on the Analysis and Design Phase of the System
Development Life Cycle. Analysis involves defining the system requirements, compiling use
cases and then developing several diagram types to aid in full system analysis. After this is
complete, the project can enter the design phase, in which system specifications and operation
details are created. User interface, program design, data storage design and system acquisition
strategies are all researched in detail to provide the best-fitting system specifications possible.
ELEC 399 Progress Report #2
21
References
A. Dennis, Roth, Wixom. Systems Analysis and Design, 5th Edition. Hoboken, NJ: John Wiley,
2012.
F. Gebali, private communication. May -July, 2012.
Bluetooth Special Interest Group. Bluetooth Technology, BT SIG. [Online]. Available: https://
www.bluetooth.org [Accessed: 28 June 2012].
IEEE-SA Standards Board: PatCom. IEEE Standards Association. [Online]. Availbale:
http://standards.ieee.org/about/sasb/patcom/pat802_11.html [Accessed: 28 June 2012].
Near Field Communication Forum. NFC Technology, NFC Forum. [Online]. Available:
http://www.nfc-forum.org [Accessed: 28 June 2012].
National Coordination Office for Space-Based Positioning, Navigation, and Timing. Global
Positioning System, GPS.gov. [Online]. Available: http://www.gps.gov [Accessed: 26 June
2012].
P. Kuber, Arduino Blog: Arduino Gets 3G Connectivity. [Online]. Available:
http://arduino.cc/blog/2012/05/29/arduino-gets-3g-connectivity/ [Posted: May 29th, 2012]
ELEC 399 Progress Report #2
24
ELEC/CENG 399 Design Project I Progress Report II Evaluation Form
To be filled by students:
Project title:______________________________________________________
Group #:_________________________________________________________
Group members:__________________________________________________
Supervisor(s):_____________________________________________________
Topics Subtopics Grade [%]
[3%]Table of contents is presented according to the
sample report attached;
[3%]Citations are properly used;
[4%]Conclusion is written in a clear professional
technical language;
subtotal [10%]: 0.0
[10%] Proposal revised according to the feedback from
the supervisor(s);
subtotal [10%]: 0.0
[20%] This chapter is written in a clear professional
technical language;
[20%] Milestones/Deadlines described in Chapter 1 are
met in timely fashion;
[20%] Overall progress is satisfactory;
subtotal [60%]: 0.0
0.0
[10%]Write the textbook review in a clear professional
technical language;
[10%]Meet minimum page requirement (2 pages).
subtotal [20%]: 0.0
0.0Total [100%]:
To be filled by the instructor:
[10%]Overall
presentation
[10%]Chapter 1,
Project Proposal
[60%]Chapter 2,
Progress Review
subtotal [80%]:
To be filled by the supervisor(s):
Progress report distributed to the supervisors for grading: Friday, July 6, 2012.
Please complete the progress report grading by: Monday, July 23, 2012.
Please refer to the rubric for grading.
[20%]Chapter 3
Textbook Review
ELEC 399 Progress Report #2
25
Comments by the supervisor:
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
________________________________________________