Prototype Parking Meter – Phase 5
Project team: May06-02

Client


Faculty Advisors


Iowa State University Parking Division
John W. Lamont, Ralph E. Patterson III
Team Members





Michael Arens
Kristi Gavin
Mikael Nielson
Ben Quach
Nichole Wittry
April 25th, 2006
Today’s Agenda






Project overview – Nichole
End product description – Mikael
Activities and milestones – Michael
Technical approach – Kristi
Resources, Schedule, and Summary – Ben
Questions
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.
Project Overview
Project Objective

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
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
Project Overview
Users and Uses
Parking Meter
System
Users Classes
and Uses
Class 1:
• ISU students
• ISU faculty & staff
• ISU visitors
Class 2:
• ISU DPS employees
Class 3:
• Administrator
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
Project Overview
Assumptions and Limitations

Assumptions





Lot size will be no more the
1000 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
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
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

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

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

End Product Description
Hardware Design
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
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

End Product Description
Hardware Design

Coin Acceptor and controller


Thermal printer


Controller provides serial
data to the motherboard
drivers provided
UPS power backup

To run unit in case of power failure
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.

Activities and Milestones
Project Research/Familiarization





Hardware
Configuration
Software Used
The Application Itself
Operating Systems
Programming
Languages





How the components
function together
Heartbeat & UltraMonkey
How to operate the
application
Windows XPe &
Debian Linux
C & MySQL
Activities and Milestones
Milestones

Project Familiarization


User Instruction Sign Completion


100% - Fully familiar with the project & still
learning
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
Activities and Milestones
Milestones

Installation of Current Unit


Support of Installed Unit


0% - Unable to install prototype unit due to software
licensing issues
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
Technical Approach
Supporting the Unit

Approaches considered:

Deal with problems on a case-by-case basis



Implement an error notification and correction process




DPS calls an emergency contact number when a failure occurs
Errors are debugged and corrected on-site
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:

Implement an error notification and correction process


Error notification is managed in a more efficient manner
Corrections can be made without spending long hours on-site
in potentially harsh weather conditions
Technical Approach
Supporting the Unit

Design Activities

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
Technical Approach
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
Technical Approach
Supporting the Unit

Testing Activities

Error Notification:

Testing of the problem-logging website will ensure
that:



E-mails are sent to the correct addresses when a
problem is submitted
The information sent in the e-mail 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
Technical Approach
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

Technical Approach
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
Technical Approach
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

Technical Approach
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

Technical Approach
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

Technical Approach
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

Resources and Schedule
Personnel Effort Requirements
Personnel Hours
275
255
252
259
249
253
250
225
Michael Arens
200
Kristi Gavin
Nikael Nielsen
175
Ben Quach
150
Nichole Wittry
125
100
Michael
Arens
Kristi
Gavin
Nikael
Nielsen
Ben
Quach
Nichole
Wittry
Personnel Effort Requirements
Resources and Schedule
Resource Requirements
Resource Requirements
Equipment and Other Resources
Item
Team
hours
Cost
Motherboard/Processor 1
0
$150.00
RAM 1
0
$80.00
Storage 1
0
$200.00
LCD
0
$75.00
Keypad
0
$90.00
Misc. Buttons
0
$50.00
Printer Controller
0
$120.00
Ethernet Switch
0
$57.00
USP Battery Backup Unit
0
$100.00
XP Embedded Run Time
License
0
$1075.00
Housing
0
$100.00
Project Poster
10
$50.00
Total
10
$2,047.00
Resource Requirements
Resources and Schedule
Financial Requirements
Financial Resources
$1,302
$150
$80
Parts
Materials
Services
Labor
$13,948
Financial Requirements
Resources and Schedule
Schedule
Project Schedule
Summary
Commercialization

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

Summary
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

Summary
Lessons Learned
Gain more knowledge/experience from
previous team
 Anticipate delays incurred from outside
sources

Summary
Risk Management

Anticipated Risks
Procurement of materials
 Data loss
 Physical damage
 Loss of team member

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.
Questions
Descargar

Prototype Parking Meter – Phase 5