ELEC 399 Progress Report #2 - UVic.cadleslie/images/ELEC_399_Progress_Report_2.pdf · ELEC 399...

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.


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


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


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.


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.


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


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.


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


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

http://en.wikipedia.org/wiki/Wired_Equivalent_Privacy

http://en.wikipedia.org/wiki/Wired_Equivalent_Privacy

http://en.wikipedia.org/wiki/Wi-Fi_Protected_Access


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


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.


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.



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:



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.


10

For both of the options listed above, an antenna will be required at minimal cost:



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


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.


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.


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.


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.


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.


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.


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.


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,


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.


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.


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]


22

Appendix A – GSM Coverage Maps


23


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


25

Comments by the supervisor:

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

________________________________________________

Date post:	22-Mar-2020
Category:	Documents
Upload:	others
View:	2 times
Download:	0 times

ELEC 399 Progress Report #2 - UVic.cadleslie/images/ELEC_399_Progress_Report_2.pdf · ELEC 399...

Documents