Proposal for awhitmore/courses/ensc305/projects/2006/obtpost.pdfInitially we built a prototype using...

School of Engineering ScienceSimon Fraser UniversityBurnaby BC V5A [email protected]

Copyright © 2006, OnBoard Travel Technologies

April 20, 2006

Dr. Andrew Rawicz & Mr. Steve Whitmore School of Engineering ScienceSimon Fraser UniversityBurnaby BC V5A 1S6

Dear Dr. Rawicz and Mr. Whitmore

Please find the attached document, Post-Mortem for a Mileage Recorder for Small Business Owner/Operators. The document provides a retrospective on the conceptualization, design and development of our ENSC 305/440 project.

The document highlights things that worked well, as well as what could have been improved. It also provides a means for each group member to reflect on their experiences with the project.

The Post-Mortem examines the current state of our device, the deviations from the original plan, each member’s personal experiences, and possible future work for the project.

OnBoard Travel Technologies is comprised of four highly motivated and skilledengineers: Bergen Fletcher, Ali Abdul-Hussein, Lena Lee, and Patrick Perrella. Pleaseforward any questions or concerns to [email protected].

Best Regards,

Bergen FletcherChief Executive Officer OnBoard Travel Technologies

Enclosure: Post-Mortem for a Mileage Recorder for Small Business Owner/Operators

School of Engineering ScienceSimon Fraser UniversityBurnaby BC V5A [email protected]


Post-Mortem for a

Mileage Recorder for Small Business Owner/Operators

Project Team: Bergen FletcherAli Abdul-HusseinLena LeePatrick Perrella

Contact: Patrick [email protected]

Submitted to: Dr. Andrew Rawicz, ENSC 440Steve Whitmore, ENSC 305School of Engineering ScienceSimon Fraser University

Issued Date: April 20, 2006Revision 1.0

4

Post-Mortem for Mileage Recorder for Small Business Owner/Operators


Table of ContentsTABLE OF CONTENTS .......................................................................................4

LIST OF FIGURES ...............................................................................................5

LIST OF TABLES.................................................................................................5

ACRONYMS.........................................................................................................5

1 CURRENT STATUS OF THE DEVICE..........................................................61.1 MRD SYSTEM ..........................................................................................6

1.1.1 Hardware Implementation................................................................61.1.2 Firmware and MRDUI......................................................................7

1.2 PC SOFTWARE SYSTEM ............................................................................71.2.1 Software GUI ...................................................................................71.2.2 Software Data Handling...................................................................8

1.3 MRD-VEHICLE LINK ..................................................................................81.4 MRD-PC LINK..........................................................................................9

2 SYSTEM DESIGN DEVIATION.....................................................................92.1 MRD & VCD HARDWARE .........................................................................92.2 MRD FIRMWARE ALGORITHMS.................................................................102.3 SOFTWARE GUI AND DATA HANDLING ......................................................10

3 PROJECT MANAGEMENT.........................................................................113.1 BUDGET DEVIATION.................................................................................113.2 SCHEDULE DEVIATION .............................................................................12

4 PERSONAL EXPERIENCES ......................................................................134.1 BERGEN FLETCHER, CHIEF EXECUTIVE OFFICER, SENIOR HARDWARE ENGINEER .........................................................................................................134.2 ALI ABDUL-HUSSEIN, CHIEF OPERATIONS OFFICER, DESIGN ENGINEER......144.3 LENA LEE, DIRECTOR OF QUALITY ASSURANCE, SENIOR TEST ENGINEER ...154.4 PATRICK PERRELLA, CHIEF FINANCIAL OFFICER (CFO), SYSTEM INTEGRATION ENGINEER.....................................................................................16

5 FUTURE WORK..........................................................................................175.1 MRD FEATURES .....................................................................................17

5.1.1 Memory Capacity Enlargement .....................................................175.1.2 Gas Mileage Calculation................................................................175.1.3 Enhanced USB Interface ...............................................................185.1.4 More Compact and Improved UI Hardware ...................................18

5



5.2 SOFTWARE FEATURES.............................................................................185.2.1 Tax Deduction Calculation.............................................................185.2.2 Enhanced File Formats .................................................................185.2.3 Graphical Data Presentation..........................................................19

5.3 WEB-CLIENT ...........................................................................................205.3.1 Software and Firmware Upgrades.................................................20

5.4 MARKETABILITY & INTELLECTUAL PROPERTY.............................................205.5 CRA CERTIFICATION...............................................................................21

6 REFERENCES ............................................................................................22

List of Figures Figure 1: Overall System.......................................................................................6Figure 2: Software Main Application Window........................................................8Figure 3: Original Timeline.................................... Error! Bookmark not defined.Figure 4: Updated Timeline.................................................................................12

List of Tables Table 1: Budget Comparison ..............................................................................11

AcronymsCRA Canada Revenue AgencyCSV Comma Separated ValueMRD Mileage Recorder DeviceMRDUI Mileage Recorder Device User InterfaceOBTT OnBoard Travel TechnologyPC Personal ComputerVAC Volts, Alternating CurrentVSS Vehicle Speed Sensor

6



1 Current Status of the DeviceAs shown in Figure 1, the system is fully functional can be connected to a pulse signal source, simulating a car VSS signal, collect trip mileage and gas purchase information and store accordingly. The user can then connect the device to the PC software, through a USB link to retrieve the required information. The following sections outline the current status of the MRD system, PC software and the links to the car and the PC.

Figure 1: Overall System

1.1 MRD System

The overall system functions exactly as described in the functional specifications. The MRD can be connected to the car through the VCD device to collect trip and gas information. This information can then be retrieved by connecting the device to a PC through a USB connection.

A PC, Window’s compatible, software is implemented to interface to the MRD and read and organize the stored information. The user can also use this software to modify trip menu items.

1.1.1 Hardware Implementation

The MRD hardware design is centred on an Atmel AVR ATMEGA16 microcontroller. The MRD employs a 2x16 character LCD display and 4 pushbuttons as a user interface. A battery-backed Real Time Clock (RTC) allows the device to time/date stamp every record it stores to a 512Kbit EEPROM memory device.

7



To provide an effective link to today’s standard PC, a Delcom USB chip is used to allow the AVR to transfer data from the MRD memory to a PC (equipped with Plug ‘n Go software).

The AVR microcontroller includes a built in counter which allows it to be used to count pulses from a Vehicle Speed Sensor (VSS), in turn providing an accurate measurement of the distance the connected vehicle has travelled.

The MRD includes only one four-pin USB type B female connector but uses multiplexing circuitry which allows this connector to be dual-purpose. The connector is used to provide the USB link to a PC (including 5V power provided by the PC) and also to provide a link to the vehicle’s power source and ignition and VSS signals.

1.1.2 Firmware and MRDUI

The embedded firmware currently can be used to execute all the originally planned functions. The user can connect the device to the car, through the VCD conditioning device, select input settings such as user name, car name, trip type and destination and then start the trip. The MRD counter algorithms can then poll the incoming VSS signal from the VCD to calculate the total mileage for the trip. This information is then encapsulated and stored into an embedded EEPROM data storage.

The user can optionally input gas purchase information; this includes the user specific information, gas volume in Letter, and gas purchase price in dollar per letter.

1.2 PC Software System

1.2.1 Software GUI

The software GUI has general layout of a Windows application. It is implemented to run on Windows XP and Windows 2000. The application has menu bar and toolbar for accessing functions. Users can execute typical Windows’ functions such as create new file, open file, save file, and print file. In addition, the menu bar and toolbar allows users to edit the configuration data on MRD with different dialog boxes. User can also launch online help through both the menu bar and toolbar. Other features offered by the menu bar and toolbar include calculating statistics of recorded data, such as total mileage and gas purchase. A screenshot of the main window of the software is shown in Figure 2.

The GUI displays all the data recorded by MRD in spreadsheet format. After the data is downloaded from MRD, users can view trip data on the main application. Gas purchase data can be viewed on a separate spreadsheet which can be accessed through the menu

8



bar and toolbar. The spreadsheet offers flexibility to the users allowing them to reorder and sort the columns.

Figure 2: Software Main Application Window

1.2.2 Software Data Handling

The back-end of the software deals with reading and writing data to and from the MRDand file system. As well, it provides data structures to store the data while the application is working with it.

Recorded data consists of both trip entries (driver, car, start/end data/time, mileage) and gas purchases. This recorded data is read from the MRD and stored in the appropriate data structures, which are in turn used by other modules of the program. It is also the responsibility of this module of the software to configure the MRD. The configuration includes custom driver, car and destination names, as well as setting the correct date, time and vehicle model (VSS information).

Likewise, the software is able to retrieve this configuration data from the MRD, and store all data (both configuration and recorded data) to the PC’s file system. The back-end is also responsible for reading data from the file system, should the user want to look back on older data, and reading configuration information (so users won’t have to re-enter configuration data).

1.3 MRD-Vehicle Link

In addition to the MRD hardware, a secondary piece of hardware called the Vehicle Cradle Device (VCD) is need. This device conditions the power source and ignition and

9



VSS signals which the MRD needs to acquire from the vehicle. The AVR microcontroller in the MRD uses the ignition signal as an indication that a trip has ended. Based on configuration parameters stored in the MRD memory, the AVR can convert the VSS signal into meaningful mileage data and record this data to memory.

1.4 MRD-PC Link

The MRD-PC link is where recorded data and configuration information are transmitted between the PC and the MRD. The physical link is made possible via a USB connection, between the USB port on the PC and the Delcom USB chip on the MRD. In order for the software to correctly interface with the USB chip on the MRD, a Delcom USB driver must be installed on the PC. Our interface code then utilized the Delcom libraries to provide for data transfer between the PC and MRD.

2 System Design Deviation

2.1 MRD & VCD Hardware

In general, the hardware design has not changed significantly from the design specified in our Design Specification document. A couple resistor values have been tweaked toprovide better performance. The major deviation from our original hardware implementation plans is that we decided to design Printed Circuit Boards (PCBs) and a have three boards manufactured.

Initially we built a prototype using an off-the-shelf perforated prototyping PCB and wired components to one another by hand. We chose to make the custom PCBs for two reasons: having three boards made would effectively allow us to build 4 prototypes (3 using the custom PCBs, 1 using the original perforated prototyping PCB); and a custom PCB is likely much more robust and reliable than a prototype board that has a mess of small wires running everywhere.

The VCD hardware changed more significantly than the MRD hardware. Our initial VCD signal conditioning hardware design was op-amp based and upon testing did not perform as required. For this reason the signal conditioning circuitry was redesigned and is now Schmitt Trigger (Hex Inverter) based.

10



2.2 MRD Firmware Algorithms

In general, we followed virtually the same design process we had initially proposed at the beginning however slight changes were required along the process.

One noticeable design deviation was the handling of data structures within the firmware. Initially we had the entire trip and gas data fields stored into 10-byte packets, and each field would take only the maximum required number of bits. For instance, the user name field will only need 2 bits since its values only ranged from 0 to 3. This required intensive bit field manipulated and caused data corruption in many events; therefore, we decided to avoid bit manipulations at all levels of the firmware and rather store each field of the trip and gas packet into one byte individually; this of course resulted in a less efficient handling of data as each trip and gas packer is now 20-byte long instead of 10; this is due to the fact that each field occupied one full byte even those fields that only ranged from 0 to 3 and required only 2 bits.

Although inefficient, we managed to sort out all data corruption and make sure that all fields are stored and retrieved accurately and easily. With this modification, our device can still hold 1 full year worth of trip and gas data.

2.3 Software GUI and Data Handling

Only one change has been made particularly in the division of functional area of the software. Both data handling and device handling functions are encapsulated. The main application creates the classes as objects and calls the suitable functions. However, file system interfacing has been merged with data handling.

Several changes have been made to the software GUI including the spreadsheet used to display data. Originally the spreadsheet was planned such that the users are able to hide columns. However, that has not been implemented. Instead, users can modify the column sizes and hide a desired column selectively.

The menu has undergone a few changes as well. Since the spreadsheet was changed to not editable by the user, the “Edit” menu has been removed. This feature was implemented to allow users to undo changes, copy, and paste text. Two functions have been added to both the menu bar and toolbar: downloading MDR configuration and uploading MDR configuration. These two functions are made available to users so that users can choose to upload and download MDR configuration at desired time.

11



3 Project Management

3.1 Budget Deviation

As is illustrated in Table 1, we went about $300 over our initial budget estimate. The main reason for this is that we decided to buy parts to build four prototypes as opposed to just one prototype. We wanted four prototypes so that upon completion, each team member could keep a prototype as a memento of the project. Additionally, requiring four prototypes allowed us to meet minimum manufacturing requirements to have custom PCBs made. Also having the ability to produce four working prototypes, three of which would be built upon robust custom PCBs, allowed us to ease our minds of potentially fatal hardware problems occurring days before demonstrating our project.

Table 1: Budget Comparison

Component/Equipment Initial Cost Estimate ($)

Actual Cost ($) Discrepancy ($)

Atmel AVR STK500 Development Kit

100.00 100.00 0.00

Atmel AVR Microcontroller 10.00 40.00 +30.00USB Interface IC 10.00 40.00 +30.00Voltage Regulators 10.00 20.00 +10.00Discrete Logic, Opamps, Misc Discrete Components

10.00 30.00 +20.00

Passive Components 10.00 30.00 +20.00Liquid Crystal Display 20.00 65.00 +25.00Prototyping Perforated Circuit Board, Enclosure

20.00 0.00 0.00

EEPROM Memory 5.00 20.00 +15.00Real Time Clock (RTC) 5.00 20.00 +15.00Other/Extra(Back-up) Components

50.00 65.00 +15.00

Custom PCBs & compatible enclosures

0.00 120.00 +120.00

TOTAL 250.00 550.00 300.00

12



3.2 Schedule Deviation

Slight changes in the schedule of tasks took place during the course of project design and implementation. The deviations were concentrated around the software implementation phase of the project. The software design started two weeks later than planned and ended one month later. The late start can be attributed to the fact that the software design team had to get involved in the firmware design efforts as some difficulties occurred at the start of the process. The deviations in timeline are shown in blue in Figure 4.

Figure 3: Updated Timeline

13



4 Personal Experiences

4.1 Bergen Fletcher, Chief Executive Officer, Senior Hardware Engineer

Working on this project above all provided me with some excellent project management experience. I was given the opportunity to take somewhat of a leadership role on our team over the course of developing our project. Taking on this leadership role was somewhat stressful at times as I felt I needed to take responsibility to make sure that all necessary tasks were given adequate attention. Our team is fairly well-rounded which made distribution of tasks easier since each member of the team had his/her strong suit and would be most effective at certain tasks.

As the member of the group with undoubtedly the most hardware design/development experience, I essentially undertook the task of designing and implementing all the hardware we needed to complete our project. While I had significant hardware development experience to draw on while taking on the task of designing our project, I had not really designed a complete hardware system from the ground-up as I did on this project. I believe going through this design process on our project, including my involvement in developing firmware and software, has allowed me to learn more of “what to do” and “what not to do” when designing circuits.

The Plug ‘n Go project can really be broken down to three subsystems: the PC software, the MRD firmware, and the MRD hardware itself. Each of these subsystems needed to be developed individually in some sense, but at the end of the term they also needed to function together. The process of integrating smaller sections of a project into one complete project I believe was a highly valuable technical skill we all acquired during the course of developing our project.

The documentation process provided us all with experience of writing together as a group. Our team had from the beginning designated a person to develop a template (or layout) of what needed to be included in the document, we then met to decide who would write each section of the document. Upon everyone writing their sections, the other members where to edit one another’s writing. The document would then be assembled and polished by a designated member. For the most part this worked quite well, and we produced some great documents, although I felt that we could have avoided some grammatical errors through more thorough editing.

I believe that the most valuable skill that can be taken from working on such a project is teamwork. Teamwork is supporting one another, being respectful and courteous, and being open to one another’s criticisms, suggestions, and ideas. While the technical skills

14



and writing skills learned throughout the course of this project were certainly extremely valuable, we could not have been successful if we had not learned to work as a team.

4.2 Ali Abdul-Hussein, Chief Operations Officer, Design Engineer

Over a long semester of working on the MRD device, I had mainly been contributing to the design and implementation of the firmware subsystem. Throughout the process, I learned how to take the correct steps towards design a firmware from scratch, which is something I have never done before this class. In previous courses, I had always been the person who design a certain function or routine of the “big program” this time however, I really felt as an engineer for the first time, and after four years of studying at SFU, while I was designing the firmware.

One basis key of success I have come to realize during the first days of the firmware design process is to present the suggested ideas properly to other team members. Firmware design, being a non physical realm, was not as easy to communicate as I initially thought; it was easy, on my party, to go and write a piece of firmware without asking the other team members, but I never wanted to do that; I wanted to make sure that every member knows what I am about to write before doing so; to achieve that, and from day one, I relied heavily on flow charts; I made a flow char for every subroutine and sent it out to the other members and made sure they all understood the full process before I write any line of code. Along the semester, my colleagues have also realized the power of this tool and communicated to me their ideas and criticism accordingly.

Beside the firmware endeavour, I also gained significant experience in hardware troubleshooting and debugging; in many events, I would find that no matter how I program a certain routine, it will never work when tested on the hardware; although I felt quite frustrated, this motivated me employ my engineering skills and try to find out “other” reasons behind a non-functional firmware; every time I run into this brick wall, I would grab my multi-meter and test the hardware connections to make sure everything is fine, and this indeed solved several problems that can not be solved at the firmware level.

Far from the technical theatre, I also experienced the full cycle of producing an audience-friendly, high level, graphical and tabular documentations of most phases of the development processes. In addition, working in a team was thing I never got to appreciateuntil half way through this term, where everyone felt that they can not do anything without the assistance of the others; we really, at most times, felt that there is no way shorter to success than consulting, helping and sharing with each other.

15



4.3 Lena Lee, Director of Quality Assurance, Senior Test Engineer

This project course offered more than just refining skills but also learning new skills. Mirroring my experience in actual workplace, I feel I have learned more from this project than the skills that I had required for working on the project. Although I was not involved much on hardware and firmware side, I still was able to learn.

On the hardware side, I often attempted to put together my own prototype with the schematics and other hardware documents that are part of this project. This is the first time that I have purchased hardware components and put it together. Unfortunately, the prototype is not functional.

On the firmware side, I was only involved in writing the interrupt service routine. However, the experience provided quite a few insights. This is the third course in which I had a project with microcontrollers. I not only learned about programming Atmel microcontroller but also learned how to debug with simulators before actually testing out my code on the hardware.

For major part of the project, I worked on the GUI design using Visual Studio 2005. This is my first time designing GUI with Windows Forms although I had experience with C++ MFC. Even though the layout of the GUI is drawn out by the program, I learned how the events are triggered. I was also responsible for taking the data from data handling objectand displaying the data in the GUI. This allowed me to become more familiar with different data types and converting and displaying the data in a desired format. I would say the most important lesson I learned from programming GUI is how to use help provided and find help online. During the programming process, I needed to look for explanations and examples frequently. I tried to use functions and libraries already provided instead of creating my own. This helped me understand better how to sift through text and links to get information that I need.

Through this project, I have also learned more about teamwork. One way is through the use of CVS. CVS helped in managing files multiple people are working on. Although CVS features are easy to use, I had problems with it and learned to work around the problems. I also refined a bit more on my communication skills. I have tendency to keep myself and not ask questions. However, throughout the project, I have asked questions that I myself considered silly. It is a good experience to learn from what happens when questions are asked.

To sum everything up, ENSC 305/440 offered a lot of learning experience in addition to refining skills. It is quite interesting and fun to work in a group on a project of this size.

16



4.4 Patrick Perrella, Chief Financial Officer (CFO), System Integration Engineer

This project provided me with an excellent opportunity to combine the many skills I have learned over the course of my engineering education. While the largest piece of my efforts went towards development of the software application (especially back-end functions), I also was involved in firmware design/development and had great exposure to all of the hardware aspects of our project. I also have purchased a complete set of parts to implement my own device prototype, but this device will likely not be fully functional by our demonstration date.

I really enjoyed the scope of the project, from high level PC software development, to lower level microcontroller programming and low level hardware issues. I also really enjoyed working on a project that has such a direct and practical application; it is a device that can be directly used to do a job.

I learned from all the technical aspects of this project. On the hardware side, I once again learned to appreciate the delicate and unforgiving nature of hardware debugging, including delicate wires and connections. I certainly learned much about Atmel microcontrollers and programming them, as well as an appreciation for the variety of microcontrollers available.

In developing firmware to interface with the real-time clock, I gained a detailed knowledge of the I2C interface. This low-level device interface is widely used by electronic components, and something I knew very little about before. On the software side I learned a great deal about Visual C++, C++/CLI (formerly known as Microsoftmanaged C++), and the .NET programming platform. However, perhaps more important than these specific technologies, was the application and further honing of the engineering skills I’ve learned through school. I gained a sense of satisfaction with finding that the basic principles I had learned, some with different technologies, were applicable with different tools.

There were many valuable non-technical learning opportunities, as well. The documents we produced were valuable in allowing us to further practice our skills at communicatingtechnical information and presenting our ideas in a professional manner. Looking back, however, I felt we should have been a bit more careful in our editing as a few too many grammatical errors slipped through.

We also worked well as a team. This proved invaluable in allowing the group to complete tasks efficiently. People issues were certainly at a minimum, and for the most part little time was wasted on “group logistics”. Part of this was efficiently breaking the project down in to small pieces that groups members could work on independently,

17



avoiding some of the wasted time when multiple people try to crowd over a work-bench or computer. Technology also helped us to collaborate effectively.

Perhaps the biggest helpful technology was our CVS server. I have used CVS a couple of times in past projects, but it was most helpful for this project. Virtually all of our schematics, firmware code, software code, and documents were updated to our central CVS server which was accessible from any of our computers or over any web browser. This proved invaluable, not only in the distribution of new revisions of code/documents, but also in making sure that everyone is “plugged in” to every part of the project. I would strongly recommend using a CVS server to any future 305/440 groups. Our e-mail list was also effective, and our primary means of communication.

All in all, I had a great experience in ENSC 305/440, and it was certainly one of the most rewarding courses I’ve taken at university.

5 Future WorkAlthough the entire system is now fully functional, due to time constrains, we were not able to implement several ideas which would have resulted in more features and robustness in our systems. The following sections outline possible future work in the hardware, firmware and software levels of the system.

5.1 MRD Features

5.1.1 Memory Capacity Enlargement

One modification that can be considered is the enlargement of the storage capacity of the MRD device. Currently, the device can hold up to one year worth of trip and gas purchase information; this is with the current 512 K bit Microchip EEPROM. This can be upgraded to 1 M bit EEPROM or even multiples of this size to increase the capacity of the device. This might also be need if other features were added and larger memory required to accommodate such features.

5.1.2 Gas Mileage Calculation

Currently, the MRD user can optionally, record gas purchase information. With such information, an overall gas mileage option can be implemented. This can be done at the firmware and software level. As for the firmware, a new function can be added to customize the gas purchase word to be specific to each user and car type. With such information, the software can calculate the gas mileage for each user and car type.

18



5.1.3 Enhanced USB Interface

While the Delcom USB chip provided us an adequate means of implementing a communication link between the MRD and a PC, future implementations of our system should probably incorporate the use of a more cost-effective, robust, and higher data transfer speed USB interface solution. One such way of achieving these requirements would be to use a microcontroller which has a built in USB interface. Another option would be to implement in firmware a USB interface on the ATMEGA16 using two of its General Purpose Input Outputs (GPIOs).

5.1.4 More Compact and Improved UI Hardware

One possible enhancement to the MRD user interface is the addition of an alphanumeric key pad. This will allow the user to add user name, car name, and destinations without having to connect to the PC. This feature will be particularly useful for those who may need to travel for long times and are not able to connect the device to the PC frequently to modify settings.

5.2 Software Features

5.2.1 Tax Deduction Calculation

Since Plug n’Go is geared toward recording trips for tax deduction purposes, the software will be enhanced to include tax deduction calculations. The Plug n’Go already collects necessary data. What is needed is to use the information and follow the format of tax deduction form to calculate tax deduction. In conjunction with CRA certification mentioned in section 5.5, this feature will save users time and increase marketability.

5.2.2 Enhanced File Formats

Currently, the software saves the data into Comma Separated Value (CSV) file format. By enhancing file formats in the future, user can port their trip and gas data between our software and other spreadsheets available on the market. This allows users to further customize the data as desired. Below is a sample of possible file formats displayed in save file dialog box.

19



Figure 4: Sample File Formats

5.2.3 Graphical Data Presentation

The software GUI currently only offers raw text representation of data. It is lacking in visuals. One way to augment this is to be able to create pie charts and bar graphs of selected data. Users would be able to also print out these graphs as reports. The graphs can provide more detailed data such as percentage of mileage per user or car usage per user. After all, graphical data is much easier to understand than text. Below is a sample pie chart for possible graphical data presentation.

Figure 5: Sample Pie Chart

20



5.3 Web-client

5.3.1 Software and Firmware Upgrades

A possible future feature of the Plug ‘n Go system is software and firmware upgrades over the Internet. An automated software upgrade feature could be added to the software which checks the OnBoard Travel Technologies’ server for new software updates. When new software is available it could ask the user if they wish to upgrade. If the answer is affirmative, it would then automatically download and install the update. This can include updates containing new lists of VSS rates, so users driving new cars do not need to manually find out (and input) the VSS rate of their car.

Likewise, this system could notify the user when new firmware versions become available, and could download them from the Internet. The user would then be able to connect the device to the computer and use the PC software to initiate an upgrade to the newest firmware version. This feature would involve additional development to both the software and firmware.

5.4 Marketability & Intellectual Property

Based on the mostly positive reaction we have received about our Plug ‘n Go system, we believe that it would have some market potential. At this point no member of our team plans to pursue the project further but have not dismissed the idea of marketing the device. We would however be reluctant to move ahead with marketing the device without performing much more market research to get a better idea of how profitable (if at all) our product could be. On the technical side of our project, we believe it is not far off from being a marketable product. We certainly believe that cost-oriented design changes should be made but overall the project itself is near a marketable level.

Before attempting to market our Plug ‘n Go system, we believe it would be intelligent to protect our intellectual property by applying for a patent. Our main reason for doing so is that we believe that we may have difficulty maintaining our position in the market should a larger company decide to market a similar product at a lower cost than which we could effectively market ours. With the patent rights to our idea, we would likely be entitled to our fair share of profits made by any company marketing a device encompasses by our patent.

21



5.5 CRA Certification

We believe that CRA certification could add a significant benefit to the marketability of our product. It would show potential consumers, who may be considering the Plug ‘n Go for tax purposes, that the product is recognized by the CRA. This may help ensure people that the product will have credibility in the event they are audited.

Earlier in the project, we researched possible CRA certification. The CRA informed us that the CRA does not have specific guidelines as to how a vehicle usage record is maintained (just that it is maintained with certain information), and that our device would likely produce a valid record for tax purposes. We also learned that while the CRA certifies tax software, they do not have any experience or current process for certifying a hardware device such as the Plug ‘n Go. The CRA employee maintained that CRA certification for our device would certainly be a possibility, but that such a process is new territory for the CRA. This leaves the door open for pursuing this certification in the event we take the device to market.

22



6 References[1] Canada Revenue Agency, Motor Vehicle Expenses Claimed by Self-Employed Individuals, December 16, 1996, http://www.cra-arc.gc.ca/E/pub/tp/it521r/it521r-e.html, Viewed: Jan 16, 2006

[2] OnBoard Travel Technology, Functional Specification, February 24, 2006

Proposal for awhitmore/courses/ensc305/projects/2006/obtpost.pdfInitially we built a prototype using...

Documents

Transcript of Proposal for awhitmore/courses/ensc305/projects/2006/obtpost.pdfInitially we built a prototype using...