ELEC 399 Final Report:

“Smart Bus System”

By

Group Number: 1 Dana Leslie (dleslie@uvic.ca) V00693424

Doug Maclean (macleadl@uvic.ca) V00711553 Harland Sims (harles@uvic.ca) V00661836

Project Website: http://web.uvic.ca/~dleslie/

Supervisor: Dr. Fayez Gebali

Submitted August 3, 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 authors.

i

Table of Contents 1.0 Goals ................................................................................................................................... 1

2.0 Project Overview .................................................................................................................. 1

3.0 Detailed Project Description ................................................................................................. 3

3.1 Design Factors and Considerations .................................................................................. 3

3.2 Description of Proposed System ....................................................................................... 3

3.2.1 Smartphone Application ............................................................................................. 4

3.2.2 Bus Electronics Module .............................................................................................. 6

3.2.3 Server Backend ......................................................................................................... 7

3.3 Use Case Walkthrough ..................................................................................................... 9

3.4 Additional Functionality ..................................................................................................... 9

4.0 Workload Distribution and Achievements ............................................................................10

5.0 Project Discussion ...............................................................................................................11

6.0 Summary and Future Works ...............................................................................................12

Appendix A: Textbook Review ................................................................................................. A1

Appendix B: Preliminary Electronics Costs/ Parts List .............................................................. B1

Appendix C: System Concept Diagrams .................................................................................. C1

Appendix D: Cellular Coverage Maps ...................................................................................... D1

References .............................................................................................................................. E1

1

1.0 Goals

The main goal of this project is to improve the accessibility of the public transit system to individuals with visual impairments. Currently, visually impaired people face many challenges when attempting to utilize the public transit system in the Greater Victoria region. These challenges include: getting to the appropriate bus stop, reading or otherwise learning the bus schedule, ensuring that the bus they are waiting for stops, boarding the correct bus and knowing when to disembark 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 smartphone 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 [1]. This work, when combined, addresses a large portion of the scope of the smart bus stop project. This still leaves several of the mentioned problems unsolved, however. One major problem that has been not addressed 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, various parties have expressed interest in a system which would notify the driver that a visually impaired user is at the stop and is intending to board (thus alleviating any potential miscommunication between a waiting user and the driver). 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. The final product of this class will be an outline of the proposed the system design which is to be further developed and prototyped during ELEC 499. This system will be a software and hardware based solution that addresses the challenges faced by visually impaired people when utilizing the public transit system in the Greater Victoria area.

2.0 Project Overview

Throughout the course of this project’s development, a great deal of research was conducted in order to determine an optimal system design. Many communications protocols were explored in order to determine those that were most compatible with today’s smart phones, as well as which could be easily implemented at bus stops or on buses. Functional requirements of the system were identified and research was conducted on the social and economic constraints the system would be subject to. Four initial system design concepts were created and the research process culminated in the selection and elaboration of the most promising system implementation.

2

A basic outline of the proposed system can be seen below in Fig. 2.1. Eschewing the use of a bus stop electronics module, it instead incorporates an on-bus electronics module with cellular data connectivity. This allows buses to communicate with a server backend, which in turn communicates with a specially-designed smart phone application on the user’s end. Cellular data connectivity is high-bandwidth, long-range and has excellent coverage within Greater Victoria (cellular coverage maps are available in Appendix D). This system achieves the stated goal of improving transit accessibility in several different ways. First, it allows visually-impaired patrons to notify the driver of their intended bus that they wish to board via application prompts. These check-in requests are bus stop, bus route, direction and pick-up time dependent, and are forwarded to the relevant bus at the appropriate time by a server system. The on-bus electronics module also incorporates a stop announcement system which externally announces the bus route and direction at each stop, allowing visually-impaired patrons to differentiate between multiple buses stopping at high-density stops simultaneously. Lastly, the application is able to present static scheduling information to users in a way compatible with their visual impairment.

Fig. 2.1 - Proposed System Overview

3

3.0 Detailed Project Description

3.1 Design Factors and Considerations

The optimal smart bus system design is the one which achieves our stated goals most effectively while still being subject to the economic and social constraints which were identified. In order to determine the most economical system design, factors such as the following were considered:

● Initial cost (infrastructure, materials, installation) ● Maintainability (resistance to vandalism, ease of repairs, cost of parts) ● Reliability (weather resistance, ability to identify and isolate faulty parts of the system) ● Recurring costs (bandwidth, server infrastructure management)

With regards to social concerns, it was learned that the blind community has a strong desire not to be singled out or publicly identified in a crowd. This was made evident during a meeting with David Guthrie, BC Transit Director of Operations for Greater Victoria, as well as a BC Transit planning employee. They had recently conducted meetings with the Canadian National Institute for the Blind and had been told this was a primary concern [2]. In addition, BC Transit explained that bus drivers are trained to pick up on body language cues to determine whether a waiting passenger intends to board their bus, but because blind patrons can be unaware of an approaching bus, that there are often miscommunications in this area [2]. Thus the desired solution is one that eliminates any confusion as to whether the bus should stop while also being discrete in nature. For more details on the prospective system designs and why the end design was chosen over the others, please refer to the Project Discussion section.

3.2 Description of Proposed System

The proposed system design can be broadly broken up into three parts: a specialized application running on the user’s smartphone, a robust backend server system responsible for database management and check-in request routing, and an electronics module mounted in each bus. Users will be able to select a bus route, direction and departure time upon arrival at a stop, based on verbal narration and simple tactile selections. After selecting the desired bus, a check-in request is sent to the server system, which then determines when to send it out to the appropriate bus based on dynamic bus tracking information, as well as static scheduling information. The request arrives at the bus via cellular data communication, and is communicated to the driver via the use of a visual and/or auditory cue. The bus electronics module interfaces with an existing onboard GPS module in order to send dynamic positioning information back to the server system. In addition, the bus will externally announce its route and direction at each stop, in order to reduce confusion at high-density bus stops. The features and details of each part of the system are explained in further detail in the following sections.

4

3.2.1 Smartphone Application

The development of a user-friendly smartphone application is one of the most important factors of this project. The application serves as the gateway to the back-end server infrastructure and allows our users to access all the benefits enabled by the on-bus hardware. For a system-level breakdown of the application’s functionality, please see Fig. 3.2. Being that the intended customers of this application are visually-impaired people, it stands to reason that this application will be unique when compared to the majority of other smartphone applications. Our application will eliminate the need for complicated tactile interaction and depend predominantly on verbal interaction with the user. It will have a very simple interface which could be cut up into halves, or quarters, and allow for easy interaction with the user. A mockup of the proposed user interface (UI) can be seen below, in Fig. 3.1.

Fig. 3.1 - Example

Application Interface

As can be seen from the UI mockup, there will be two main modes

of operation. The first is called “Find a Stop” and concerns itself

with the task of checking a user in at a bus stop. Being in close

geographic proximity to a bus stop will initiate a verbal

announcement and allow the user to check-in at the stop. The

second UI option is called “Schedule Information” and will serve

the aforementioned to the user in a visually-impaired friendly

manner. Prior to checking-in at a bus stop, it will provide static

schedule information, and if currently checked-in, it will serve only

the upcoming stop times. This functionality will become even more

valuable if the dynamic bus tracking information the server system

gathers is exposed to to users (see section 3.4, Additional

Functionality, for more information). This may lead to the ability to

alert users of bus delays, and estimate the next busses time of

arrival with a greater degree of accuracy.

5

Fig. 3.2 - Application / Smart Phone System Diagram

6

3.2.2 Bus Electronics Module

The electronics module that will be integrated with the bus’ systems consists of multiple subsystems all tied together by a micro-controller. This includes a communications system, an audio system, and a driver notification I/O system. Additional general integration with the existing bus GPS logger, paddle information and related systems will be needed throughout. Please note that the pricing information alluded to in the following paragraphs is tabulated in Appendix B. Figure 3.3 shows a system overview of how the module will operate.

Fig. 3.3 - Bus Detailed System Diagram

7

The communications method that was decided on was to use a cellular data connection; although there are associated service fees that will need to be paid to the cellular carrier, this choice was selected due to the high level of existing coverage and low cost to implement (no need for new infrastructure). As a reference baseline for the service fees, BC Transit’s HandyDART service currently pays $34/month/vehicle for cellular data connectivity [3]. The hardware needed to implement this is a Quad Band GSM module that can be interfaced with the microcontroller, these range in price from $40 to $100 and have a price break when purchased in bulk. The main traffic will be communication between the webserver and the controller on the bus and will consist of downloading flags to notify the driver that a blind or disabled user is waiting at a stop ahead and uploading route/GPS location data with a unique bus identifier; this will be intermittent in order to keep bandwidth down.

The purpose of the audio system is to externally announce route information to bus patrons before they board and could potentially could be expanded to internally announce upcoming stops to passengers (similar to the SkyTrain system in Vancouver). This would consist of a speaker located near the front door and an audio amplifier and driver circuit. This system will potentially need to be fairly loud due to the large amount of noise pollution in which busses operate most of the time; the price for a sufficient amplifier and speaker is projected to be around $30. It will also need a fairly large amount flash memory in order to store the audio files, so a SD/MMC breakout board and card will be needed ($6.50 + $4.50). This system would need to be interfaced with bus systems for ease of stop detection as well as attaining route information. This subsystem could be isolated from the communications system if processing power becomes an issue.

Another system is the driver notification system. This would be controlled directly by the micro-controller and could be as simple as an indicator LED or a minor LCD display; this would vary in cost from a few cents to hundreds of dollars. If the LCD display option is selected, it is likely that a more sophisticated controller system would need to be chosen and is thus considered out-of-scope for the 499 project unless external funding is acquired.

The final and most important component is the microcontroller. For the purposes of prototyping, the Arduino Uno microcontroller was selected due to its flexibility, low cost ($15-25), and user-friendly programming environment. It utilizes the ATMega328 chipset which can be cheaply purchased and combined with a specialized PCB to lower ultimate manufacturing costs once a working prototype has been built. There are all the necessary modules, or shields, available for purchase that connect directly to the I/O pins of the micro-controller to allow for easy prototyping. One small issue is the lack of Flash Memory available with off-the-shelf Arduino’s, so it is very likely that additional memory will have to be purchased and interfaced.

3.2.3 Server Backend

The server infrastructure necessary to support the application and bus electronics can be broadly divided into three interconnected systems: the user check-in system, a dynamic bus location database, and static schedule and bus stop coordinate database. Fig. 3.4, below, shows a detailed diagram of these systems and the main functionality each of them is responsible for.

8

Fig. 3.4 - Server Backend Detailed System Diagram

The system which receives bus stop check-in requests from users would first place a new request into a queue of unserved requests. For each unserved request, the system would then determine which bus is to service the request and check the buses most recent location update against the stop which the user is waiting at (via interface with both other backend systems). Once this information has been gathered, the system would determine whether the request should be sent out immediately (meaning the bus is close to the requested stop) or placed into another queue of waiting, fully-processed requests. Each request in this queue would then be sent out once the target bus gets within a certain distance threshold of the requested stop. The dynamic bus location system is responsible for receiving periodic location updates from each active bus. It would then maintain an approximate position and progress status on each bus, which allows for much more accurate check-in request timing than a purely static timing implementation. The static bus schedule and stop coordinate database would hold the most recent version of the transit system’s schedule and bus stop list. This system would then be responsible for sending updated copies of its information to user’s smart phone applications, should a connecting user’s local data be deemed out-of-date. Simple version checking could be performed via transmission of date last modified or version hash tag by the application.

9

3.3 Use Case Walkthrough

In a typical use case scenario, a potential user would go through the following steps when utilizing our service: First, while walking down the road toward a bus stop, the user would enter the “Find a stop” mode. This would initiate a comparison between the users current geographic location and the geographic location of known bus stops. Once the user walked into sufficiently close proximity of the bus stop, a verbal announcement would notify them, and they would be presented with the ability to check-in at the stop. Next they would be required to specify the route and time they wish to board the bus. At this point they have successfully checked-in and will wait for the bus. This successful check-in will send the bus driver a notification via our server backend and ensure they stop at the specified stop, as well as allow them to take the necessary precautions when boarding the visually-impaired rider. Lastly, upon bus arrival, the on-bus hardware and speaker system will verbally announce the bus number arriving, to avoid confusion in high traffic areas and allow for independent boarding.

3.4 Additional Functionality

Although our current implementation aims to address the issues surrounding the challenges blind people face when riding public transit, there are many simple modifications that can carried out to make our project valuable to all public transit users. With the utilization of on-bus GPS and GSM modules, we are able to dynamically track all connected busses. The backend infrastructure that would have already been established could be modified to utilize bus location information for various other functions. Specifically, we could use this information to inform the user if there is a delay on a specific route or estimate the time of the next busses arrival. This dynamic bus tracking information could also be integrated into a Google Maps application utilizing their API (Application Programming Interface) allowing for online, or in application, dynamic bus tracking maps. Some additional functionality that would require extra or modified hardware could be to expand the on-bus audio subsystem to announce upcoming stops. This is much like that function that exists in Vancouver’s Sky-Train system and would require a larger number of sound clips to fully implement. Another subsystem add-on could be a more sophisticated bus driver notification system. This could consist of an LCD display showing the specific stop information at which a disabled user is waiting and would require additional information to be communicated to the bus (this functionality is also discussed above, in section 3.2.2). Lastly, we have identified that the services we are developing would be of benefit to all public transit users, and as such, an application could be developed to be utilized by non-visually impaired users. This application would eliminate the verbal dictation functionality and simple interface found on our blind-friendly application and would depend more on tactile input and offer more robust schedule information and maps. It would also eliminate the ability to check-in at a stop and focus more on being a next-bus-like service.

10

4.0 Workload Distribution and Achievements The majority of the stages in this project's progression were aided by all three group members. The initial stage of the project involved clarifying intended functionality with the project supervisor and generating a list of factors to consider during implementation design. A list of potentially suitable communications technologies was then created, and the research workload broken up between all three group members. After the most suitable technologies has been identified, the four initial system design concepts were created (with joint participation by all group members). At this point, the simple system diagrams were created by Dana Leslie, while Doug Maclean and Harland Sims focused on comparing potential hardware costs of each of the concepts through research of the components necessary. After meeting with BC Transit officials and gathering more information, a final decision was made as to which system design to use going forward. The third major stage of the project involved elaboration and investigation of the chosen system design, as well as preparation for the final presentation. The presentation and this final report were both group efforts, aided by each member. Workloads for this particular stage can be broadly categorized as follows: Dana Leslie - Project website

- User application elaboration Doug Maclean - Bus electronics module elaboration & component research - Communicated with potential additional 499 group members (SENG) Harland Sims - Communication with outside information sources - Server back-end elaboration Major achievements during this stage of the project were completion of technology research, consultation of BC Transit to determine their specific needs and the suitability of our concept designs, selection of a system design based on this meeting and prior criteria, and elaboration of that design into a detailed system description. The creation of a project website, a set of presentation slides and a final report documenting our findings are also considered achievements, as these are tools which can be used going forward to help demonstrate our idea. As this project is carried into ELEC 499 and the focus changes from research to system prototyping, group roles are expected to become more defined (as different portions of the system to be prototyped will need to be delegated to different people). A large portion of the 499 work will be application and software systems based, and as such it is expected that additional team members (of a more software-centric background) will be needed. Doug Maclean has approached and secured the interest of two software engineering students who are eager to join the effort should this project be carried into ELEC 499. The addition of two dedicated software team members will greatly strengthen the group.

11

5.0 Project Discussion

As described previously, the first stage of the project culminated in the creation of four distinct ideas for system implementations. Although they all would have successfully achieved the goals we set forth, some of them were deemed not economically feasible. The chosen system diagram can be seen in Fig. 2.1, while the other three can be found in Appendix C. All three discarded system concepts involved bus stop electronics packages. While initially favoured over on-bus electronics for their lower price (due to being able to leverage a user’s smartphone for long range data transfer) and less complicated integration process, many factors discouraging the use of bus-stop electronics were identified as the project progressed. Bus stop electronics were deemed much more susceptible to vandalism than bus electronics, as well as being more costly to both install and repair (due to their scattered locations). Lastly, and most importantly, it was learned that BC Transit services approximately 2500 stops in the Greater Victoria region using a fleet of 270 total conventional buses [2]. This means that while an on-bus electronics module may be more expensive than a bus-stop module on a per-unit basis, the cost multiplier of placing electronics on every stop (or even just all major stops) is much higher than for every bus. This effectively ruled out implementations involving bus stop electronics. Before the major disadvantages of bus stop electronics were fully clear, the most promising design was thought to be the system incorporating a Bluetooth-enabled bus stop with an LED indicator mounted on it. It was able to notify the bus driver that there was a visually impaired patron desiring board the bus by means of this stop-mounted light. Each Bluetooth-enabled stop would possess a unique identifier, allowing the application to verbally convey stop-specific schedule information to the user through their smartphone. As mentioned in Section 3.1, after meeting with BC Transit it came to our attention that blind people do not wish to be identified or singled out in any way, a desire which would be hard to reconcile with a large LED check-in indicator mounted on the bus stop. For this reason, as well as the economic considerations mentioned earlier, the implementation involving direct notification of the bus driver via onboard electronics was chosen.

12

6.0 Summary and Future Works In the first of our two senior design classes, ELEC 399, our group has successfully developed an implementation strategy for a smart transit system. The intention of this system was to aid visually impaired riders in utilizing public transit and provide them with information that they have otherwise would have been unable to obtain. Our system will combine on-bus hardware with a smartphone application, which the two linked together via a server backend. In developing this implementation strategy, many milestones have been met. These milestones include comprehensive research into the available technologies, research into the preferences of the blind community, as well as the operations-logistics and statistics of BC Transit in the Greater Victoria region. Research into the hardware requirements, limitations, maintainability and costs was also conducted. This research has allowed us to confidently refine our implementation and expand the expected functionality within our existing hardware selections. The next design class, ELEC 499, will focus on the construction and demonstration of a working prototype of our system. This prototype will include a functioning hardware module that could be placed on a transit bus, a functioning smartphone application that will cater to visually-impaired users and a server-side backend that will link the two. The prototype of our implementation will be one of a kind and as such, may not encompass all the hardware minimizations and fabrication optimizations that would be developed for an enterprise-level level rollout. Similarly, the proof-of-concept server-side backend will be developed with only our hardware in mind and may not be able to handle the traffic seen in a real-world scenario. None the less, we aim to develop a fully working prototype than can be utilized to demonstrate a complete service walkthrough and prove the functionality listed in our project description.

A - 1

Appendix A: Textbook Review

Continuing from where Part 3 left off, Part 4 of Systems Analysis and Design, 5th Edition focuses on the last major steps of the system development life cycle. Part 4 is concerned with the implementation of and transition to the system which was fully designed in Part 3. Broadly, this encompasses managing the successful programming of the system, testing it thoroughly and documenting it both internally and for end users. Last is the process of transitioning from the current system to the new system, something which must be handled well in order to guarantee quick and voluntary user adoption of the new system. Central to the success of system implementation is effective project management of the programming team. Coordination is key to project success during this time but becomes more and more difficult as team size increases, thus an effort should be made to keep the programming team as small as possible while still having enough people to complete the project. Management tools which can be leveraged to improve coordination include regular team meetings, encouraging all programmers to follow standard practices which are set down at the beginning of the project, use of versioning control software (such as Subversion or SVN) and use of CASE (computer-aided software engineering) tools. The most common reasons for project delay during this phase are scope creep and unnoticed or unreported slippages, both of which can be largely mitigated using the above techniques. Testing of the programmed system is vital to producing a working product. Because a system can be quite complex, tests must be planned carefully and thoroughly to encompass all possibilities. There are several types of tests possible: unit tests (which test a single module or program within the system), integration tests (which test module interconnections), system tests (which examine the system as a whole to verify functionality) and acceptance tests (which are performed by end-users in order to ensure they can accept the new system). Also to be done during this phase is the main system documentation. The new system will likely be used for some time, by a large number of people, and thus good system documentation will help alleviate user and maintenance problems far into the future. Documentation can be broadly broken up into two main categories: user documentation and system documentation. System documentation is written with programmers, support and maintenance staff in mind. It describes the inner workings of the systems, configuration and troubleshooting steps, as well as possibly justifying design decisions. User documentation, however, is aimed at the end user, and this should be kept as free of technical details as possible. Three main types of user documentation are considered: reference documentation (which is to be used when a user needs to learn how to perform a specific function), procedure manuals (which describe business tasks which can be performed by the system, and how to perform them), and tutorials (which aim to teach new users how to operate the system). The addition of some form of

A - 2

navigation controls to the documentation will help reduce the amount of time a user spends searching for a solution to a problem, and thus also help alleviate frustration with the new system. Examples of navigation controls include a table of contents, a search feature, a glossary, bookmarks, etc. With implementation done, all that remains before the system is operational is initial rollout and transition to it from the old system. This step is crucially important—a bad transition can leave users feeling frustrated and greatly hamper acceptance and adoption of the new system. The transition process is broadly broken up by Lewin into three steps: unfreeze, move and refreeze. The unfreeze step involves breaking people’s existing habits with regards to the old system in order to better facilitate change, the move step involves the actual physical system transfer, and the freeze step symbolizes encouraging users to form new habits and practices utilizing the new system. The move step is in part facilitated by a migration plan, which outlines a system conversion strategy and contingency plans should anything unexpected happen during the transition. The technical side of the migration plan is fairly straightforward: uninstall the old system (if applicable) and install the necessary software and hardware for the new one. Any stored data which will be needed by the new system should be converted if necessary. The migration plan should also outline a user migration policy, which may include plans for training, adoption motivation techniques to encourage quick switching, as well as any management policies which may help facilitate an effective system switch. The final portion of this stage of the SDLC is support of the new system. System support staff can be broadly divided into several categories. Level 1 support staff generally interact directly with users: answering phone calls, handling support questions. Level 2 support staff are responsible for dealing with issues elevated by level 1 staff, issues deemed challenging or indicative of a system bug. They will be responsible for generating bug reports when applicable. Maintenance staff are the people responsible for overseeing correct system functioning, as well as handling the requests for change coming in from various parties (bug reports from support, for instance). In order to better go about future system development and implementation, a review of the whole process may be performed at this stage. This will allow system architects to learn from any mistakes made during the process and improve upon them. In addition, a review dealing with whether the initially stated benefits of the new system were fully realized may be performed at this stage. With this comes the end of the system development life cycle, from initial functionality idea to complete, fully operational system.

B - 1

Appendix B: Preliminary Electronics Costs/ Parts List

Major Components Required:

Qty Description Price ($) Reference

1 Arduino Uno (ATMega328) 15.20 3

(1) Arduino Mega2560 (Optionally, has more power) 17.99 3

(10) Max 10cmx10cm 2-layer PCB printing 9.90 2

(10) ATMega328 /w bootloader 27.70 1

1 GSM/GPRS Wireless Shield w/ Antenna 48.00 2

(1) Serial LCD 1602 Module (Driver Notification) 13.00 3

(1) EM-411 GPS Engine Board Module 28.30 3

(1) STA540 Audio Amp (38W) 29.95 4

1 VMA2016 Audio Amp (10W) 13.43 3

1 10W (102mm) Water resistant speaker 1.50 5

1 SD-MMC Breakout board 6.50 2

1 2GB SD Card 4.50 3

Estimated Cell Fees 34/mo

Total prototype cost estimate $90 - 150 +$34/mo

Note: Italic listings are not required for completion of basic project, for extra features or alternatives. Parts references: [1] - ebay.com [2] - elecfreaks.com [3] - dealextreme.com [4] - sparkfun.com [5] - alibaba.com

B - 2

Note that costs associated with server hardware have yet to be estimated and are not included above. Server costs for the 499 prototype will differ wildly from those of a full-scale system (as hardware needs to be scaled to the expected amount of traffic, and is thus proportional to user base and number of connected buses).

C - 1

Appendix C: System Concept Diagrams Note that the diagram of the chosen implementation can be found in section 2, titled Fig. 2.1. Blue arrows indicate Bluetooth communication and red indicate cellular data communication. Unused Implementation #1 (Bluetooth between both smart phone and bus):

C - 2

Unused Implementation #2 (Bluetooth between phone and bus stop with LED check-in indicator):

Unused Implementation #3 (Data and bluetooth enabled bus stop):

D - 1

Appendix D: Cellular Coverage Maps Telus Mobility coverage map for CRD:

D - 2

Rogers Wireless coverage map for CRD:

References Citations: [1] Gebali, Dr. Fayez, private communication. June 2012. [2] Guthrie, David et al., BC Transit, private communication. July 2012. General References: A. Dennis, Roth, Wixom. Systems Analysis and Design, 5th Edition. Hoboken, NJ: John Wiley, 2012.

ELEC/CENG 399 Design Project I Final Project Report Evaluation Form To be filled by students:

Project title: Smart Bus system

Group #: 1

Group members: Dana Leslie, Doug Maclean, Harley Sims

Supervisor(s): Dr. Fayez Gebali

To be filled by the supervisor(s):

Progress report distributed to the supervisors for grading: Friday, August 3, 2012

Please complete the progress report grading by: Friday, August 17, 2012

Please refer to the rubric for grading.

Grade [%]

0.0

To be filled by the instructor:

0.0

0.0Total [100%]:

[20%]Appendix A:

Textbook Review

[5%]Chapter 1, Goals :

[10%]Chapter 2, Progress Overview:

[25%]Chapter 3, Detailed Project Description:

[25%]Chapter 4, Workload Distribution and Achievements:

[10%]Chapter 5, Project Discussion:

[5%]Chapter 6, Summary and Future Works:

Topics

Subtotal [80%]:

[10%]Write the textbook review in a clear

[10%]Meet minimum page requirement (2 pages):

Subtotal [20%]:

Comments by the supervisor: ________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________