1. Prototype Parking Meter – Phase 5
Project team: May06-02
Client
Iowa State University Parking Division
Faculty Advisors
John W. Lamont, Ralph E. Patterson III
Team Members
Michael Arens
Kristi Gavin
Mikael Nielson
Ben Quach
Nichole Wittry
Title, team name, client, facutly, team members,
April 25th, 2006

2. Today’s Agenda Project overview – Nichole
End product description – Mikael
Activities and milestones – Michael
Technical approach – Kristi
Resources, Schedule, and Summary – Ben
Questions

3. Project Overview Problem Statement
Parking on or near campus has become a concern at Iowa State University
ISU currently has two pay-for-parking lots that have computerized parking meter system units with receipt printout capability.
These current system units lack ability to communicate with each other causing data tracking problems and user inconvenience.
If a current system unit is disabled, all data is lost.
The current system units are difficult to program and/or adjust.
The cost of each NEW programmable unit begins at $10,000 and rapidly escalates to more than $75,000 as features are added.
abstract

4. Project Overview Project Objective More flexible Cheaper than systems
Objective is to develop a microprocessor-based parking meter system that is:
More
flexible
Cheaper than systems
currently available on
the market
Able to Communicate with itself between units
By collaborating with the ISU Parking Division, the objective of this project is to develop a demonstrable, microprocessor-based parking meter unit that is cheaper and more flexible than Iowa State’s current parking meter system.

5. Project Overview Operating Environment Subject to weather of Ames, IA
Must withstand temperature extreme’s from -30° F to 115° F
Must withstand all forms of rain, snow, and hail
Must be resistant to abuse and vandalism

6. Project Overview Users and Uses Parking Meter System Users Classes
ISU students
ISU faculty & staff
ISU visitors
Class 2:
ISU DPS employees
Class 3:
Administrator
There are three defined classes of users for our new parking meter system. The first class is made up of all of the ISU students, faculty, and visitors who will use the parking lot. They can purchase parking time in one of three ways. They can either start by inserting coins, or they can enter the desired end time, or they can enter the total time they wish to park.
The second class of users is made up of the ISU DPS parking division employees who will use the parking meter system to monitor the paid and unpaid lot spaces, and gather parking lot usage statistics.
The third class of users is made up of the Administrators who have all of the capabilities of the class 2 users, but have the added capability to change the hourly parking rates, set holidays, and add and delete class 2 users.
Class 1 Uses:
Purchase parking time in 3 ways
Start inserting coins
Enter desired end time
Enter desired total time
Class 2 Uses:
Monitor paid and unpaid spaces
Gather parking lot usage stats
Class 3 Uses:
Change hourly rates
Set holidays
Add and delete class 2 users

7. Project Overview Assumptions and Limitations Assumptions Limitations
Lot size will be no more the spaces
Units will not provide change
AC power will be provided to the unit
Units will accept only nickels, dimes, and quarters as payment
ISU facilities will install the system
Limitations
Must implement all the features of the current system
Must withstand Iowa outdoor conditions
Must be theft proof
Must have redundant processing and storage

8. Project Overview Where Does Our Team Fit In?
Previous teams have already designed and constructed a functioning prototype unit.
Our goals were:
Get the prototype unit ready for testing in Armory lot
Support prototype unit out in Armory lot
Build a second slave unit

9. End Product Description
System Specifications
The master unit that contains the server information runs Linux OS
The server will have a dual processor design to ensure reliability
Maintained up to date using UltraMonkey software tools
Information stored in a MySQL database
Connected to multiple slave units directly with Ethernet

10. End Product Description
System Specifications
Slave units will use Microsoft Windows XP embedded
Provides drivers for ease of use adding devices
Application written in C++
MySQL used to access database
Connects to a master unit through Ethernet connection

11. End Product Description
Hardware Requirements
The slave machine will use off the shelf parts and be easy to replicate
Will need to have the same functionality as the existing unit

12. End Product Description
Hardware Design

13. End Product Description
Hardware Design
Via Epia 800 MHz motherboard
Contains an integrated
processor, Ethernet, USB,
serial ports
256 MB PC133 RAM
512 MB Disk on chip
Holds application and OS

14. End Product Description
Hardware Design
Storm 16-key keypad
Off the shelf and drivers to support
Backlit keys for night visibility
LCD display
4 lines by 40 character display
Must withstand Iowa weather extremes

15. End Product Description
Hardware Design
Coin Acceptor and controller
Controller provides serial
data to the motherboard
Thermal printer
drivers provided
UPS power backup
To run unit in case of power failure

16. Activities and Milestones
Project Research/Familiarization
As we are phase 5 of this project, there is a lot to familiarize ourselves with and not so much research to be done.
Familiarization also includes familiarizing new teams about the project as they come on.
Understanding of both the physical and software sides of the system are the most important.

17. Activities and Milestones
Project Research/Familiarization
Hardware Configuration
Software Used
The Application Itself
Operating Systems
Programming Languages
How the components function together
Heartbeat & Ultra- Monkey
How to operate the application
Windows XPe & Debian Linux
C & MySQL

18. Activities and Milestones
Project Familiarization
100% - Fully familiar with the project & still learning
User Instruction Sign Completion
100% - The sign is complete and ready for install with the parking meter unit
Testing of Current Prototype Unit
90% - Application fully tested, still working on some hardware testing

19. Activities and Milestones
Installation of Current Unit
0% - Unable to install prototype unit due to software licensing issues
Support of Installed Unit
50% - Have completed a plan to handle problems, but can’t fully support it until after installation
Building of Second Unit
85% - In progress
Found replacements for discontinued parts
All of the parts have arrived
Working on the building of a new case

20. Technical Approach Approaches considered: Approach used:
Supporting the Unit
Approaches considered:
Deal with problems on a case-by-case basis
DPS calls an emergency contact number when a failure occurs
Errors are debugged and corrected on-site
Implement an error notification and correction process
Problems are reported by DPS via an online form that automatically notifies team members and advisors
Coding errors are debugged using a duplicate unit located in the lab
Fixes are uploaded via a laptop connection to the on-site unit
Approach used:
Error notification is managed in a more efficient manner
Corrections can be made without spending long hours on-site in potentially harsh weather conditions
Once the current unit has been installed into the parking lot, it will be our team’s responsibility to provide support should the unit experience a failure of some sort. To do this, we considered two different approaches. The first approach would involve dealing with problems on a case-by-case basis. Should the system goes down, DPS would contact us using an emergency number, and we would attempt to resolve the issue on-site to the best of our ability. The second approach relies instead upon an error notification and correction process. Rather than calling an emergency number, DPS would report problems using an online form that would automatically team members and advisors to notify them of the failure. Also, rather than attempting to resolve the issue by bringing our resources out into the parking lot to fix the failure on-site, this approach would involve building a duplicate unit that we could keep in the lab to use for simulating failures and debugging the code. Fixes could then be uploaded via a laptop connection to the on-site unit. In the end, we chose to go with the second approach, as we feel that it deals with error notification in a more efficient manner, and allows us to resolve the issue indoors, without spending long hours on-site in potentially harsh weather conditions.

21. Technical Approach Design Activities Supporting the Unit
Error Notification:
Work with DPS to decide what information will need to be collected when an error occurs
What steps led to the error, what time the error occurred, etc.
Design a problem-logging website that DPS can use to effectively report problems online
Error Correction:
Design of the replica unit will match that of the original
Design a method of uploading software fixes on-site
Design a method of documenting problems and problem resolutions
To carry out this approach, several design activities are needed. In regards to the error notification process, we will first work with DPS to decide what information will need to be collected when an error occurs, details such as what steps led to the error, what time the error occurred, etc. We will then use this information to design a problem-logging website that DPS can use to effectively report problems online. As for error correction process, the design of the replica unit will match that of the original, which has already been decided upon by previous teams. However, designs will still need to be laid out to determine a method of uploading the software fixes to the on-site unit, as well as how to document problems when they occur.

22. Technical Approach Implementation Activities Current status:
Supporting the Unit
Implementation Activities
Current status:
Building of the replica unit has begun
A preliminary problem-logging webpage has been developed
Future team will show to DPS for approval or revision ideas
Our current status in regards to implementing these activities is that we have recently received parts for the replica unit and have begun it’s construction within the lab, and we have also developed a preliminary version of the problem-logging website, that we will soon be showing to DPS to get their approval and/or revision ideas.

23. Technical Approach Testing Activities Error Notification:
Supporting the Unit
Testing Activities
Error Notification:
Testing of the problem-logging website will ensure that:
s are sent to the correct addresses when a problem is submitted
The information sent in the matches the input submitted on the form
Error Correction:
The same test cases designed for the original unit will be verified on the replica unit
To test that our error notification process works, we will checking our problem- logging website to ensure that s are sent to the correct addresses when a problem is submitted, as well as that the information sent in the matches the input submitted on the form.
To test the error correction process, the same test cases that were designed for the original unit will be used to verify the functionality of the replica unit so that we can be sure our debugged code and fixes will function properly when uploaded to the original unit.

24. Technical Approach Documentation Activities
Supporting the Unit
Documentation Activities
All problem reports and solutions will be documented and stored using a predefined format
Test cases will be updated if necessary
To document the support process, all problem reports and solutions will be documented and stored using a predefined format. Also, any test cases that were modified will be reflected in updated test case documentation.

25. Technical Approach Approaches considered: Approach used:
Building the Second Unit
Approaches considered:
Follow the software specification written by previous teams
Improve upon the existing design
Research new technologies
Approach used:
Follow the software specification written by previous teams with only minor improvements
Provides consistency between units
Allows for easy maintenance of multiple units
Minor improvements will only affect the physical casing of the internal components
The other main goal of our team’s project was to begin the construction of a second unit to be placed in the parking lot along with the existing unit. To do this, we considered two approaches. The first involves following the software specification
The first approach would be to follow the software specification written by previous teams, and the second would be to improve upon the existing design by possibly researching new technologies. As the one of the main goals of this project is to produce a unit that will be replicable in the future, we chose to go with the first approach, and only add minor improvements. This will provide consistency between the units, and allow for easy maintenance. The only improvements made would be in the design of the physical casing used to hold the internal components. Our first case was donated to us, which made arranging the internal hardware more difficult. This time we will be able to customize the inside of the case to hold or hardware more effectively.

26. Technical Approach Design Activities
Building the Second Unit
Design Activities
Design of hardware and software was previously determined by other teams
Design an improved casing with the help of the ME students
Design additional test cases to verify communication between units

27. Technical Approach Implementation Activities Current status:
Building the Second Unit
Implementation Activities
Current status:
Building of the second unit has begun
ME students are working to build case for second unit according to our specifications

28. Technical Approach Testing Activities
Building the Second Unit
Testing Activities
The same test cases designed for the original unit will be verified on the second unit
Additional test cases will be run to verify the network communication functionality between units

29. Technical Approach Documentation Activities
Building the Second Unit
Documentation Activities
Test cases will be updated to reflect additional network testing
If necessary, updates will be made to the software functional description and/or the hardware assembly documentation

30. Resources and Schedule
Personnel Effort Requirements
Personnel Effort Requirements

31. Resources and Schedule
Resource Requirements
$2,047.00 10
Total
$50.00
Project Poster
$100.00
Housing $
XP Embedded Run Time
License
USP Battery Backup Unit
$57.00
Ethernet Switch
$120.00
Printer Controller
Misc. Buttons
$90.00
Keypad
$75.00
LCD
$200.00
Storage 1
$80.00
RAM 1
$150.00
Motherboard/Processor 1
Cost
Team hours
Item
Equipment and Other Resources
Resource Requirements
Resource Requirements

32. Resources and Schedule
Financial Requirements
Financial Requirements

33. Resources and Schedule
Project Schedule

34. Summary Commercialization Opportunities:
With the added functionality and flexibility of the system the market would welcome our product
Off the shelf parts ensure easy reproducibility
Once the prototype unit has had in lot testing, a standard case design, and a proven support plan, the product would sell well

35. Summary Future team’s responsibilities:
Future Work
Future team’s responsibilities:
Continue to support and maintain parking meter system
Implement a method of uploading software fixes on-site
Resolve XP embedded licensing issue

36. Summary Gain more knowledge/experience from previous team
Lessons Learned
Gain more knowledge/experience from previous team
Anticipate delays incurred from outside sources

37. Summary Anticipated Risks Procurement of materials Data loss
Risk Management
Anticipated Risks
Procurement of materials
Data loss
Physical damage
Loss of team member

38. Summary
Parking has become an important challenge lately in urban centers and universities.
An efficient and low-cost meter system will help the University to focus on alleviating the parking problem directly.
Will save time and money
Flexible and architecturally simple.
Future changes to the system can be implemented should the need arise.

39. Questions