Prototype Parking Meter – Phase 6
Final Report
Project team: Dec06-02
Client
Iowa State University Parking Division
Advisors
John W. Lamont, Ralph E. Patterson III
Team Members
Kristen Goering, Ryan King,
John Scapillato, Justin Smith
DISCLAIMER: This document was developed as a part of the requirements of an electrical and computer
engineering course at Iowa State University, Ames, Iowa. This document does not constitute a professional
engineering design or a professional land surveying document. Although the information is intended to be
accurate, the associated students, faculty, and Iowa State University make no claims, promises, or
guarantees about the accuracy, completeness, quality, or adequacy of the information. The user of this
document shall ensure that any such use does not violate any laws with regard to professional licensing and
certification requirements. This use includes any work resulting from this student-prepared document that
is required to be under the responsible charge of a licensed engineer or surveyor. This document is
copyrighted by the students who produced this document and the associated faculty advisors. No part may
be reproduced without the written permission of the senior design course coordinator.
November 10, 2006
Table of Contents
Item
Page
List of Figures
List of Tables
List of Definitions
1. Executive Summary
1.1 Need for Project
1.2 Actual Project
1.3 Previous Accomplishments
1.4 Present Accomplishments
1.5 Required Future Activities
2. Acknowledgement
3. Problem Statement
3.1. General Problem Statement
3.2. General Solution Approach
4. Operating Environment
5. Intended Users
6. Intended Uses
7. Assumptions
8. Limitations
9. Expected End Product and Other Deliverables
9.1. Multi-space Parking Meter System
9.2. Complete Parts List and Assembly/Setup Instructions
9.3. Support Plan
9.4. End-user documentation
9.5 Instruction Sign
9.6 Project Plan
9.7 Design Report
9.8 Final Report
10. Project Approach and Results
10.1 End-Product Functional Requirements
10.2 Design Requirements and Constraints
10.3 Approaches Considered and Used
10.4 Detailed Design
10.5 Implementation Process
10.6 End-Product Testing
10.6.1 Testing Methodology
10.6.2 Testing Results
10.7 Product End Results
11. Estimated Resources and Schedules
11.1 Estimated Resources
11.2 Schedules
iv
v
vi
1
1
1
2
3
3
3
3
3
4
5
5
6
6
6
7
7
7
8
8
8
8
8
9
9
9
9
11
16
21
21
21
23
23
23
23
28
ii
Table of Contents (cont.)
12. Project Evaluation
13. Commercialization
14. Recommendations for Additional Work
15. Lessons Learned
16. Risk Management
16.1 Anticipated Risks
16.2 Anticipated Risks Encountered
16.3 Unanticipated Risks Encountered
16.3.1 Windows XP Embedded Licensing
16.4 Resultant Changes
17. Project Team Information
18. Closing Summary
19. References
28
30
30
31
32
32
33
33
33
33
33
34
35
iii
List of Figures
Item
Page
Figure 10.4-1 – Client Unit Hardware Block Diagram
Figure 10.4-2 – Flowchart for Customer Functions Software
Figure 10.4-3 – Flowchart for Administrator Functions Software
Figure 11.1-1 – Original (blue), Revised (red), and Actual (green)
Figure 11.2-1 – Project Schedules
16
19
20
25
28
iv
List of Tables
Item
Page
Table 11.1-1 – Personnel Effort Requirements (original)
Table 11.1-2 – Personnel Effort Requirements (updated)
Table 11.1-3 – Other Resource Requirements (original)
Table 11.1-4 – Other Resource Requirements (updated)
Table 11.1-5 – Financial Requirements (original)
Table 11.1-6 – Financial Requirements (updated)
24
24
25
26
26
27
v
List of Definitions
A
AC: Alternating current, the form of electrical power most commonly used in the United
States.
B-C
C++: An object-oriented programming language popular for its ease of use and
debugging.
D
DPS: The Department of Public Safety, the entity responsible for all aspects of security
on the Iowa State University campus.
E
Ethernet: The current standard for high-speed computer-to-computer communications.
F-G
Gantt chart: a chart indicating the schedule for a project.
H-I-J-K-L
Linux: An open-source operating system.
M
MySQL: An open-source database system used on Linux.
N-O-P-Q-R-S-T-U-V-W
Windows XP Embedded: A small version of the Windows XP operating system tailored
to embedded computer applications (such as the parking meter system described
in this document).
vi
List of Definitions (cont.)
X-Y-Z
x86: The dominant processor architecture on the market today.
processors make use of x86 architecture.
Intel and AMD
vii
1. Executive Summary
The following is a summary of the Prototype Parking Meter – Phase 6 senior design
project. It will briefly cover the need for the project, the actual project, previous teams’
accomplishments, present team’s accomplishments, and the work that has yet to be
completed to finish the project.
1.1 Need for Project
Traditional parking meter systems require one unit for every parking spot. In contrast,
two of the existing lots at Iowa State have been installed with computerized parking
meter units that are able to accept money, print receipts, and track multiple spaces from
one or two locations. This setup provides advantages over the traditional parking meters,
such as the ability to monitor the entire lot and collect money from one location.
However, there are still several problems with the current Iowa State parking meter
system. The current parking meter units lack the ability to communicate with one
another. Also, if a user wishes to add time to a parking space for which they have already
paid, they must return to the same exact parking meter unit. The current parking meter
units are difficult to program and require a specialist from a company that no longer
exists. Finally, the cost of a new parking meter system to replace the current system and
overcome these problems is too expensive for the university to consider. The cost of each
new programmable unit begins at $10,000 and rapidly escalates to more than $75,000 as
features are added.
1.2 Actual Project
By collaborating with the ISU Parking Division, the objective of this project is to develop
an improved parking meter system to monitor the pay-for-parking lots at Iowa State
University. This system will be similar to the current pay-for-parking lots implemented
on the Iowa State University campus, but will allow for more functionality and
flexibility. The new system will also be more affordable, user-friendly, and easier to
maintain.
Commercial systems on today’s parking meter market implement single processor
designs. Our approach to the problem was to develop a parking meter system that
implements multiple units, all of which will communicate with a central parking meter
server though a set of master/slave connections. This allows communication between
units, and for users of the lot to be able to add time via any parking meter unit. The new
system will also allow DPS parking enforcement officers to receive a single list of lot
activity instead of multiple lists. In addition, the system will have a redundant central
processor and additional memory, which will create a much more robust solution than is
currently available.
1
The new parking meter units will have an easy to use interface that will make them more
user friendly, and allow DPS to effectively maintain the parking meter system. Finally,
the system will be implemented with standard computer hardware, which will make
duplication easier and decrease the cost of construction and maintenance of the parking
meter units.
Along with the actual parking meter, other software and hardware is required to make the
project useful. Once the parking meter makes it into the parking lot, it will be hard to
solve problems on location. This dictated the need for a simulator that can be kept in an
inside lab to be able to simulate problems and simulate solutions. Once solutions have
been found, they need a way to get to the meter that is in the lot. That is where the idea
of a laptop updating system comes from. These objectives are supplemental to making
the prototype parking meter unit.
1.3 Previous Accomplishments
Not including the current Dec06-02 team, there have been five previous teams that have
worked on the prototype parking meter project.
The May04-02 team created a complete problem definition for the project containing
uses, assumptions, limitations, functional requirements, management procedures, and
success evaluation criteria. They also researched hardware and software to meet the
project functional requirements.
The Dec04-02 team selected hardware and software for the project implementation, and
completed the project design. They also defined and functioning product that would meet
the design requirements, specifications and client needs.
The May05-02 team completed the creation, customization, and installation of Windows
XP Embedded to the slave computer’s storage device. They also completed the software
classes and functional description, and implemented the software classes used. The
May05-02 team also installed and configured the SQL database for the master units, and
performed some basic customer testing and bug fixing.
The Dec05-02 team completed a parts list for a second prototype slave unit, wrote a
formal test plan and executed test cases, and resolved code problems and hardware issues
with the prototype unit.
The May06-02 team assisted in the continued testing of the prototype unit, developed a
sign for instructing users out in the parking lot, ordered parts for a future second
prototype slave unit, began work on an in house simulator unit and resolved a runtime
license issue with the XP Embedded software.
2
1.4 Present Accomplishments
This current Dec06-02 project team, began construction on the second prototype slave
unit, properly installed XP embedded, the rebuilt the software, and created a detailed plan
for technically supporting the new parking meter system once it is placed into the Armory
parking lot. The team also started planning on the laptop updating system and finished
up the in house simulator.
1.5 Required Future Activities
Future prototype parking meter teams will have a few more activities to accomplish.
They must provide continuing and effective support of the new parking meter system
once it is installed in the Armory parking lot. They must also complete construction on a
second parking meter slave unit, create a housing unit for the second unit, provide a user
manual, and put the finishing touches on a simulation system capable of debugging and
solving problems from the parking meter lab. Lastly, a major activity will be to develop a
method of loading software fixes and changes to the parking meter system by linking a
laptop to the parking meter units.
2. Acknowledgement
The project team would like to thank the following people for their time, ideas and
financial contributions to the project: Doug Houghton of the Department of Public
Safety, Iowa State University, the May04-02, Dec04-02, May05-02, Dec05-02,May06-02
electrical/computer engineering senior design teams, the Mechanical Engineering 466
students, and Jason Boyd. The project team would also like to acknowledge our project
advisors, Dr. John W. Lamont, and Professor Ralph Patterson III for their advice and
guidance with the project.
3. Problem Statement
The following sections will provide a general overview of the problem to be addressed,
and how this project will provide a solution for it.
3.1 General Problem Statement
When this project was originally undertaken the availability of parking on or near campus
was a concern at Iowa State University. Now that is no longer a large concern of the
University, however, controlling the spaces that are currently in use is a concern. In an
attempt to give DPS a better way to monitor the current parking spots, the University has
chosen to install parking meter systems. Traditional parking meter systems require one
3
unit for every parking spot at a cost of $300 per meter. In contrast, two of the existing lots
at Iowa State have been installed with centralized parking meter units that are able to
accept money and track multiple spaces from one or more locations. This setup provides
advantages over the traditional parking meters, such as the ability to monitor the entire lot
and collect money from one location.
However, there are several problems with the current Iowa State parking meter system.
The current parking meter units lack the ability to communicate with one another. This
means that when the lot is checked for offenders, each parking meter unit must be
checked individually. Also, if a user wishes to add time to a parking space for which they
have already paid, they must return to the same exact parking meter unit. Finally, the lack
of communication between the parking meter units means that if one unit is disabled, all
of its stored data is lost.
Another problem is the current parking meter units are very difficult to program. DPS has
requested the ability to program in university holidays, as well as change the hourly rates.
The current units used to require that this be done by a specialist, who was flown in from
British Columbia, Canada. This is expensive and postpones problems that may need
immediate attention. However, this company is no longer in existence; therefore DPS
must be capable of updating the software themselves. The City of Ames has also
expressed interest in undertaking a joint venture with DPS to have similar parking meter
systems installed around the City.
3.2 General Solution Approach
This project will attempt to solve these problems by providing an improved parking
meter system to monitor the pay-for-parking lots. This system will be similar to the
current pay-for-parking lots implemented on the Iowa State University campus, but will
allow for more functionality and flexibility. The new system will also be more affordable,
user-friendly, easy to reproduce, and easier to maintain.
The parking meter system in development may be implemented with many units, all of
which will communicate with a central parking meter server though a set of master/slave
connections. Users of the lot will be able to add time via any parking meter unit. The new
system will allow DPS parking enforcement officers to receive a single list of lot activity.
In addition, the system will have a redundant central processor and additional memory,
which will create a much more robust solution than is currently available.
The new parking meter units will have an easy to use interface that will make them more
user friendly, and allow DPS to effectively maintain the parking meter system. Finally,
the system will be implemented with standard computer hardware, which will make
duplication easier and decrease the cost of construction and maintenance of the parking
meter units.
The May04-02 senior design team completed the first phase of the project. This group
completed much of the initial design work. The second group, Dec 04-02, completed the
4
design and partly implemented a prototype unit. The third group, May05-02, was
responsible for completing the prototype unit and producing a user’s guide for the
system. The May06-02 team is responsible for testing the prototype unit, and producing a
parts list and assembly/setup instructions, began the resolution to the runtime errors. This
team, Dec06-02, will be responsible for assisting in the continued testing of the prototype
unit, building a second slave parking meter unit, and developing a parking meter
simulation system for use within the lab. The Dec06-02 team will also assist in the
creation of a user’s manual for DPS, and rewrite the test cases to account for the new
standardized rates given by DPS.
4. Operating Environment
The new parking meter system will be installed in the north-east portion of the parking
lot west of the Armory building at Iowa State University in Ames, IA. It must be able to
withstand extreme temperatures ranging from -30° F to 115° F. The parking meter units
will also be able to deal with all forms of precipitation such as rain, snow, and hail.
The parking meter units will be used on a regular basis, and often by users that may treat
the unit roughly. Because of this, the units must be durable and designed to withstand
extended users. Finally, because the units will be located on a college campus, it must be
sturdy, and resistant to attempts at vandalism.
5. Intended Users
There are three classes of users will use the system:
First class:
 The customer. This includes the following categories of users:
o College students at Iowa State University.
o Faculty and staff of Iowa Sate University
o Visitors to the Iowa State University campus
Second class:
 The administrator. The Iowa State University Department of Public Safety student
employees. They need additional functionality in order to monitor the parking
lots.
Third class:
 The supervisor. This user will have to access to all the features available to
supervisor class.
5
6. Intended Uses
The system will have three classes of user (see above).
For the first class of users, that park in the lot, the system will:
 Allow parking spaces to be paid for by a specifying an amount of time, specifying
an end time, or inserting money.
 Allow time to be added to any parking space from any unit in lot.
 Print a hard-copy receipt if the user desires.
For the second class of users, the Department of Public Safety, the system will:
 Allow DPS to monitor paid and unpaid parking spot in the lot.
 Allow DPS to gather parking lot usage statistics.
For the third class of users, the Department of Public Safety, the system will:
 Allow DPS to monitor paid and unpaid parking spot in the lot.
 Allow DPS to gather parking lot usage statistics.
 Allow DPS to change hourly rates and set holidays.
 Allow users to add and delete second and third class users.
7. Assumptions
The list below is all the assumptions that the group is taking into account when designing
the system:
 The lot size will be equal or no more then 1000 spaces.
 Ac power will be provided to the unit.
 The units will only accept nickels, dimes, and quarters as payment.
 The units will not provide change to customers
 Iowa State University Facilities Department will install the system
 Adequate finances will be available to build a second slave unit
 Dec05-02 team provided parts list and assembly instructions
 Subsequent systems will be made based on the documentation generated by the
current project team
8. Limitations
The list below is all the limitations that the group is taking into account when designing
the system:
 The system must allow for different rates, time of day, holidays rates.
 The units must allow users to add time to their current amount of time.
 The hardware unit must provide the current payment status of the parking lot.
6













The servers unit must consist of two redundant processors with automatic failure
protection.
DPS must be able to change rates and holidays without outside assistance.
The system must implement all the features of the current system.
The unit must withstand Iowa outdoor conditions.
The unit must be theft proof.
The user interface needs to be compact and easy to use.
The hardware unit must print a receipt upon request.
The server unit must have redundant storage
The unit must be able to run for at least four hours if power goes out
Users should be able to add time to their current remaining amount
The parts list for the subsequent units must consist of parts which are low-cost,
interchangeable, backwards-compatible with the current prototype, and readily
available
Laptop system must be able to use USB connections for updating the unit.
Laptop must be able to support the same software system as the unit.
9. Expected End Product and Other Deliverables
The end products for this project will be a fully functional server/client multi-space
parking meter system, a secondary client unit in production by the May07-02 team, a
cookbook containing assembly/setup instructions for subsequent units, a complete parts
list, a support plan for the master/slave unit once it is in use, and a laptop updating
system. Also, documentation on the basic functions of the parking meter system will be
made available to DPS so that their employees can learn how to use the system.
9.1 Multi-space Parking Meter System
This system will consist of one or more client computers connected to a central server
computer. The system will be capable of handling up to 1000 parking spaces. The server
unit will store all of the parking lot information. The client unit(s) will retrieve this
information and act as the interface from which parking time is purchased and
administrators and/or supervisors can update pay rates, change parking schedules and
manage the parking lot. A secondary client unit will be built using the parts list and
assembly/setup instructions described below. It will then be tested and supplied to DPS
by the May07-02 and future senior design teams. These units will have a fully licensed
copy of Microsoft Windows XP embedded that will allow them to run continually
without expiration.
9.2 Complete Parts List and Assembly/Setup Instructions
The parts list is a document containing a complete list of hardware parts needed to build
either a client or a server parking meter unit. This list has changed from previous
semester’s list due to former parts no longer being available. The team was able to find
parts made by the same company with the same functionality, and the list was updated to
7
reflect these changes. The assembly/setup instructions are contained in a cookbook that
details the steps required to assemble the hardware for a server or client unit and to
correctly set up the software to run the parking lot application. This documentation is
meant to allow the building of subsequent parking meters using the same
interchangeable, cheap, easy-to-acquire parts.
9.3 Support Plan
Once the unit is completed and put into use for monitoring Iowa State University parking,
problems may be encountered. In the event that the system fails or is not working
properly, the Parking Division will need to have a way to get the problem solved as soon
as possible. The Dec06-02 team has designed a strategy so that the Parking Division can
get a hold of the team and get the problem solved with minimal down time. This strategy
will be discussed in more detail later in the document.
9.4 End-user Documentation
The current team will provide a set of documentation instructing employees of DPS how
to use the parking meter system. A list of common operations, and the instructions for
performing those operations, will be generated for each of the three classes of users for
the parking meter system.
9.5 Laptop Updating System
The laptop system will be used to update the software on the machines using an USB
interface. This will prevent the technicians from having to physically remove the board
from the unit. The system will be designed by the Dec06-02 team.
9.6 Project Plan
The project plan is a document that defines that project and the plan for the completion of
the project. It describes how design decisions were made for the project and defines the
overall problem domain. This document was delivered in February of 2006.
9.7 Design Report
The design report is a document describing the overall design of the project. It is
intended to provide all the details necessary for replication of the project by an
independent team. This document was delivered in April of 2006.
8
9.8 Final Report
The final report is a document that provides the most complete description of the project
along with a record of its development. It contains all aspects of the project, from the
background development to the testing and end product description. This document also
provides suggestions for future work on the project. This document will be delivered in
December of 2006.
10. Project Approach and Results
This section discusses the Dec06-02 team’s major project activities, including
requirements, design, implementation, and testing.
10.1 End-Product Functional Requirements
The key functional requirements that the Dec06-02 team is concerned with are the
requirements for the second client unit. The second client unit will perform identically in
hardware software functionality and user (customer/administrator/supervisor) interfaces.
It will therefore meet all functional requirements defined in the functional specification
produced by the May05-02 team.
10.2 Design Requirements and Constraints
The entire project was done under the following constraints and considerations.

Weather resistance
The entire system must be able to withstand all possible weather conditions
present throughout the year on the Iowa State University campus. These include
temperatures ranging from -30° F to 115° F, as well as precipitation, severe winds
and associated debris.

Durability
The system must be durable, long-lasting, and secure. Since it will be built above
ground, it must be able to withstand theft attempts, vandalism, corrosion, and
minor collisions.

Power requirements
The master/slave system must run off of standard 110 V AC power, as well as
have the ability to run off of battery backup in case of main power failure.
9

Hardware requirements
The master unit stores a single database for all slave units in a single parking area.
The master must use redundant processing and storage capabilities to decrease the
chance of failure. The point of redundant processing is to protect against failure,
it does this by having one of the two processors doing all the processing until it
fails. In the case of a failure, the secondary processor automatically picks up
where the primary processor left off. The slave unit will use only a single
processor and have considerably less storage than the master. The slave unit will
require these parts, also: LCD unit, coin acceptor, receipt printer, printer heater,
keypad, miniature computer case, and external housing unit. Producing a second
unit will require exact duplicates of each of these hardware parts.

Connectivity requirements
The system must communicate exclusively over a standard Ethernet interface.
The laptop update system will communicate to the units via USB.

Parking meter unit size requirements
The external housing unit must be large enough to hold all the hardware pieces
securely, but should not be so large as to be visually obtrusive.

Machine Size Requirements
The external housing unit must be large enough to hold all the hardware pieces
securely, but should not be so large as to be visually obtrusive.

Server-System Hardware Using Dual Processor Design
A system of this type will utilize a dual-processor scheme that allows the second
processor to automatically carry the load should the first processor fail. It has
redundant storage capability with its two sets of storage memory. This scheme
helps prevent downtime so that the unit can continue operating even after a minor
hardware failure.

Programming Languages
The following programming languages have been used by previous teams to
create the parking meter software application.
o MySQL
MySQL will allow easy creation of the central database, and offer crossplatform compatibility between Windows and Linux.
o C/C++
The C language will allow for creation of a modular, easily modifiable,
software program.
10

Carbon copy functionality – second slave unit
The second slave unit will perform identically in hardware/software functionality
and user (customer/administrator/supervisor) interfaces to the primary unit. It will
therefore meet all functional requirements defined in the functional specification
produced by the May05-02 team.

Carbon copy functionality – system simulation
The parking meter simulation system will be required to perform identically to the
actual primary unit’s hardware and software functionality and user
(customer/administrator/supervisor) interfaces to assist in future debugging and
support.

Easy Updating System -- Laptop
The laptop will provide DPS with an easy way to update the software on the units
without having to take the unit out of the lot to make system updates. The system
will be designed so that any slave will update itself with the new version of the
software when the primary slave unit is updated with the new software. The
laptop will communicate with the system via USB connectivity.

Additional requests from DPS
Additional functionality requests may be received from DPS personnel. These
requests, if feasible, will be fulfilled and implemented on all prototype units.

Support of Testing
The teams will supply DPS with a form to document any problems encountered.
These forms will be given to the teams to investigate the problem(s) and possible
solutions. The team members will be available via email to fix problems that need
quick attention. Contact numbers will be provided on request for DPS for
problems needing immediate attention.
10.3 Approaches Considered and Used
Previous groups had already selected or recommended most of the technical approach
considerations before the Dec06-02 team became part of the project team, as the primary
server and client units had finished initial development. This team’s specific technical
considerations were in how to support the unit once it is placed in the parking lot, how to
replicate it to create the second client unit, and how to update the system using a laptop.
The approach used by previous teams to construct the server unit was to create a dualprocessor redundant computer, running Linux on an x86 architecture. This off-the-shelf
unit allows for reliability and quick and easy software development, as the architecture is
common.
11
The approach used by previous teams to construct the client unit was to create a single
processor computer that supported all of the user interface peripherals: coin acceptor,
printer, keypad, and LCD screen.
The software package chosen by previous teams needed to be robust and feature-filled.
C++ was chosen to implement this package. C was also considered, but C++ was chosen
for better object-oriented support. For the client, the development environment was
selected to be Windows XP Embedded. For the server unit, a distribution of the Debian
Linux operating system was selected. The database system, located in the server unit,
was chosen to be MySQL, since it offers cross-platform compatibility between the server
and client.
This team’s approach to designing the second client unit was already determined in
specifications drawn up by previous teams, and will closely mirror the method used to
build the original unit. By following the same design for the second client unit, ease of
maintenance and ease of replication will be preserved.
The laptop updating system will be able to handle the same software as the unit. This will
enable DPS to make updates to the software solely at the master unit, rather than
individual units, via laptop. The software will be updated on the simulator and tested
fully. Once the updated software is working to expectations on the simulator, it will be
loaded onto the laptop and then placed on the master unit via a USB connection.
When determining how best to support the unit upon its installation into the parking lot,
two methods were considered. The first method involved dealing with problems as they
would occur, on a case-by-case basis. This would require giving DPS an emergency
phone contact number that they could use whenever a system failure occurred. Errors
would then be debugged and corrected on-site by the parking meter team until a solution
was found.
The second approach to supporting the unit would involve the implementation of an error
notification and correction process. Using this process, problems would be reported by
DPS via an online form that would automatically notify parking team members and
advisors when a problem is found. Using the information supplied by DPS, coding errors
would then be debugged using a simulation unit located in the lab. Once a solution is
found, fixes would then be uploaded via a laptop connection to the on-site unit.
The solution is a combination of the two approaches. There will be forms generated and
given to DPS that will allow them to record any problem that occurs. From there, DPS
will notify the team, either by phone or e-mail, that there was a problem. The team will
then collect the forms, attempt to solve the problem, and fill out another form with the
solution to the problem for future reference.
12
The Dec06-02 team chose to implement the second approach of supporting the unit, as it
manages error notification in a more efficient manner, and allows corrections to be made
without spending long hours on-site in potentially harsh weather conditions. The next
two pages contain examples of the support forms that have been made.
13
ISU PARKING METER SUPPORT REQUEST FORM
This portion to be filled out by parking stall occupant
Date: ___________________________
Time: ___________________________
Name: __________________________
Phone: __________________________
Email:____________________________
Location of Meter Used: __________________________________________________
Date/Time Technical Difficulty Identified: ___________________________________
Description of Actions Taken Before Difficulty Occurred (Be Specific):
Description of Meter Response to Actions Taken (Verbatim if possible):
This portion to be filled out by Parking Division
Request Accepted By: ____________________________________________________
Date & Time Submitted to Support Team: ___________________________________
Problem ID Number:_____________________________________________________
Signature: ______________________________________________________________
14
ISU PARKING METER SUPPORT SOLUTION
Problem ID Number:
_________________________________
Date & Time Problem Addressed: ___________________________
Solution Initiated By:
_________________________________
Location of Meter: _______________________________________
Date/Time Technical Difficulty Identified: ___________________________________
Description of Problem:
Solution Implemented:
Date/Time of Solution_____________________
15
10.4 Detailed Design
This section describes the detailed design that will be followed to construct the second
prototype parking meter, as well as the error reporting, and the laptop updating system.
For the second prototype parking meter, since the same servers will be used to support
multiple prototype parking meters, the client unit is the only portion of the system that
must be duplicated. Figure 10.4-1 is a block diagram of the hardware design of this
system, which is used for user interaction.
Figure 10.4-1: Client Unit Hardware Block Diagram
The specific parts required for the client unit are listed below along with their purchase
location and price.
Motherboard
Via Epia 800 MHz motherboard
Source: http://www.mini-box.com
Cost: $150.00
Notes: Motherboard contains integrated processor. Additional needed features include
onboard Ethernet, USB ports, serial port and additional serial port header.
Slave Board Case & Power Supply
Travla C158-90W Black
Source: http://www.caseoutlet.com
Cost: $128.00
Notes: This was just an affordable option. Any mini ITX case will do.
16
RAM
Crucial 256 MB PC133 RAM
Source: http://www.crucial.com
Cost: $40.00
Notes: Any ram will do.
LCD Module
Matrix Orbital LCD4041
Source: http://www.matrixorbital.com
Cost: $118.00
Notes: This LCD module was selected because it provided a 4 line by 40 character
display, as well as a serial output. No drivers needed.
Solid State Memory
M-Systems MDI1151-D512 512MBflash Module
Source: http://www.tri-m.com
Cost: $100.00
Notes: Serves as the Hard disk. No moving parts and it uses an IDE interface.
Keypad
StacoSwitch M151XX05
Source: http://www.stacoswitch.com
Cost: $90.00
Notes: Provides the needed key configuration and is backlit
Keypad Controller
Motorola 6805 and enclosure
Source: (salvaged from old keyboard)
Cost: $0
Notes: Allows the keypad to be plugged into the client computer’s PS2 port. Custom
made, for more information contact John Kassie (715-897-0048).
Keypad Controller Enclosure
Source: http://www.digikey.com
Cost: Unknown
Notes: Any enclosure will do, depending on the size of the controller.
Coin Acceptor
Coinco Global 700
Source: Iowa State DPS
Cost: $0
Notes: DPS has extras of these on hand as they are used in the current parking meters.
This item connects to the coin acceptor controller (MDB2PC).
17
Coin Acceptor Controller
Upstate Networks Incorporated MDB2PC
Source: http://www.upstatenetworks.com/mdb/
Cost: $300.00
Notes: This converts the MDB protocol outputted from the coin acceptor to serial data
that the computer can read. No drivers needed.
Coin Acceptor Controller Enclosure
SR171B-ND black plastic project enclosure
Source: http:www.digikey.com
Cost: $9.73
Notes: Any 4.88 X 6.88 X 1.5 or similar enclosure will do.
Thermal Printer
Fujitsu FTP-639MCL
Source: http://www.ipcprint.com
Cost: approx. $350.00
Notes: Connects to the client via USB. Drivers are located at
http://seniord.ece.iastate.edu/may0502/printer/W2K_XP_Fujitsu-1.03.10.zip
Coin and Printer Power Supply
Infinite Peripherals SPU-230-24IP
AC power in 24VDC power out
Source: http://www.ipcprint.com
Cost: $69.00
Notes: Dual power supply provides power for both the printer and the coin acceptor /
controller card.
Battery Backup (UPS)
APC BK650MC
Source: http://www.newegg.com
Price: $80.00
Notes: This model was selected because of dimensions, but any UPS will do.
Outer Case
Source: Old UNI parking meter case
Price: Unknown
Windows XP Embedded Run Time License
Source: Microsoft.com
Price: $79
Laptop
Source: DPS or Computer User’s Group
Price: $0
18
Outer Case
Source: The case for the second unit may possibly be manufactured by the team’s mechanical
engineering students. The outside appearance and interface will closely match that of the
original unit.
Cost: Unknown
and Figure 10.4-3 show the design of the customer and administrator menu
options that will be available to system users via the system software application.
Figure 10.4-2
Figure 10.4-2: Flowchart for Customer Functions Software
19
Figure 10.4-3: Flowchart for Administrator Functions Software
The design of the error reporting system will involve working with DPS to decide what
information will need to be collected when an error occurs. This will include information
such as what steps led to the error, what time the error occurred, etc. A final version of
the forms will need to be approved by DPS before it is made available for use online.
The laptop updating system will be able to handle the same software as the unit. This will
enable DPS to make updates to the software solely at the master unit, rather than
individual units, via laptop. The software will be updated on the simulator and tested
fully. Once the updated software is working to expectations on the simulator, it will be
loaded onto the laptop and then placed on the master unit via a USB connection.
20
10.5 Implementation Process
This project team’s primary implementation activities involved preparing the original unit
for installation into the Armory parking lot, preparing customer use instructions, devising
a method of supporting the unit once it is installed, and beginning construction of the
second slave unit to be added.
In order to prepare the original unit for installation into the Armory parking lot, a few
loose ends needed to be resolved. The first of these consisted of properly installing the
Windows XP Embedded software needed to run the client application. By working with
the team’s advisors, contacting representatives from Microsoft Corporation, and with the
help of the May07-02 team members, the Dec06-02 team was able to properly install a
functional version of Windows XP Embedded.
To ensure that customers know how to use the unit once it has been installed, instructions
were written up by the May06-02 team that gave step-by-step details on how customers
may purchase parking time using the various methods offered by the software. These
instructions were approved by the team’s advisors and by DPS, and will be placed on a
sign near the unit upon its installation into the parking lot.
A preliminary version of the error reporting forms have been created and will be shown
to both the team’s advisors and to DPS for approval.
Parts have been received to begin construction on the second client unit. While most of
the internal connections and software installation will be done in conjunction with the
May07-02 team, the finished construction, installation, and testing of the second client
unit will be deferred to just the May07-02 team.
10.6 End-Product Testing
This section describes the testing methodology used by the May06-02 team to test the
primary server and client units and some preliminary results of this testing. The testing
methodology for the primary server/client unit once it has been delivered to the parking
division is also discussed. Testing issues identified with the second client unit are also
identified.
10.6.1 Testing Methodology
Several forms of testing were and are required before the prototype parking meter unit
can be installed for testing in the Armory lot.

Pre-field and Field Testing
Testing must occur before the system is placed in the parking area.
21
o The existing client unit has been tested once for full functionality in all
user interfaces, and will undergo another round of testing prior to
placement in field. Testing included all user interfaces, all boundary
conditions, and extreme cases. This pre-field testing phase is complete,
and the unit is prepared to be mounted semi-permanently for field-testing.
o Field-testing will involve operation of unit in a ‘real-life’ non simulated
environment for a specified period of time. The May07-02 team will work
closely with DPS so as to ensure proper operation and timely fixes should
any problems arise.
o Continued testing will happen after the initial unit is installed. A duplicate
unit will be constructed and will be kept in the team’s testing room. This
unit will be used to re-create issues found with the unit being field-tested
and to test solutions to any software bugs that may be discovered in the
field.

Hardware Testing
The second client unit will require thorough testing upon completion. Tests will
be conducted to verify that the unit performs as required; specifically, it should
perform identically to existing functional client unit. Testing will be completed
by as many people as possible, including all May07-02 group members. Tests
will be well-documented to ensure timely fixing of any problems to be
encountered.

Software Testing
The same software running on the original client unit will also be installed on the
second unit, and must be tested to ensure proper operation. The software will be
tested against existing implementations to ensure uniform operation between
units.

Simulation system testing
The simulation system will be tested for full functionality using the same test
cases developed for the actual master and slave units.

Laptop Update System
To ensure the laptop system will properly replace the existing code with an
updated version of the code, the team will need to upload the updated software
onto the laptop and then onto the simulator PC that is running the outdated
version of the software. After it is uploaded the team will ensure that the
simulator is indeed running the updated software. If the updated version runs on
the simulator, it will be assumed it will run on the primary unit because the
primary unit is mimicked by the simulator.
22
10.6.2 Testing Results
Working with the May06-02 team, five major rounds of software testing have been
completed to verify the functionality of the application. These testing rounds have each
identified bugs with the parking meter software. As of the date of this report, all known
bugs within the parking meter software have been fixed. Regression testing was used to
verify that the software changes made fixed the bugs in question. There is no bug-free
software, however, this team, in conjunction with the May06-02, has done everything in
its power to ensure that no major bugs exist within the code and that the primary
server/client unit is ready for delivery to the parking division.
This team was also responsible for testing various hardware components inside the
primary server/client system. During testing, it was found that the original heating
element was not operational, and a replacement part has consequently been ordered and
recieved. This team also discovered that the battery backup supply that was originally
inside the unit was insufficient to meet the power requirements demanded of our system
and a new backup supply was ordered and recieved. A power surge problem has also
recently surfaced that has caused other hardware failure. Upon the discovery of the cause
of the power surge and subsequent testing of these parts, the primary unit will be ready
for installation into the Armory parking lot.
10.7 Project End Results
As of the date of this report, the primary server/client parking meter system has not yet
been delivered to the parking division. However, the Dec06-02 team feels optimistic that
the parking meter system will be delivered in the beginning of the Spring 2007 semester.
The May07-02 team will continue with building the second client unit in the Spring 2007
semester.
11. Estimated Resources and Schedules
This section describes an estimate of the resources required to complete this project.
Table 11.1-1 and Table 11.1-2 show the original and updated tables of team member effort
for the following tasks. Figure 11.1-1 shows the actual effort invested by each team
member. Tasks 6 and 7 are partially omitted as tardiness in the ordering of parts and the
acquisition of Windows XP embedded runtime licenses pushed back their full
completion.
11.1 Estimated Resources
 Task 1 – Project Familiarization
 Task 2 – Update Spec Sheet and Design Document
 Task 3 – Testing of the Current Unit
 Task 4 – Preparation and Installation of Unit
 Task 5 – Support Unit
23



Task 6 – Build Second Unit
o Subtask 6.1 – Hardware Assembly of Second Unit
o Subtask 6.2 – Installation of Software
o Subtask 6.3 – Testing of Second Unit
Task 7 – Parking Meter Simulation System
o Subtask 7.1 – Installation of Software
o Subtask 7.2 – Testing of simulation system
Task 8 – Design and Implement a Laptop Update System
o Subtask 8.1 – Ordering parts
o Subtask 8.2 – Design and Implementation of software
o Subtask 8.3 – Install and test the software
Table 11.1-1: Personnel effort requirements (original)
Table 1 - Personnel Effort Requirements
Name
Ryan
King
John
Scapillato
Kristen
Goering
Justin
Smith
Total
Task
1
Task
2
Task
3
Task
4
Task
5
Task 6
Task 7
Task 8
6.1
6.2
6.3
7.1
7.2
8.1
8.2
8.3
36
40
18
6
40
6
8
24
4
12
0
20
1
215
40
50
21
0
10
10
4
35
2
6
3
25
5
211
37
52
20
7
15
12
2
36
1
8
0
16
4
210
32
39
19
5
36
4
10
22
5
15
1
23
2
213
145
181
78
18
101
32
24
117
12
41
4
84
12
849
Total
Table 11.1-2: Personnel effort requirements (updated)
Table 2 - Personnel Effort Requirements
Name
Ryan
King
John
Scapillato
Kristen
Goering
Justin
Smith
Total
Task
1
Task
2
Task
3
Task
4
Task
5
Task 6
Task 7
Task 8
6.1
6.2
6.3
7.1
7.2
8.1
8.2
8.3
46
40
25
10
40
6
8
24
4
12
0
20
1
236
52
50
24
8
10
10
4
35
2
6
3
25
5
234
51
52
23
8
15
12
2
36
1
8
0
16
4
228
45
39
21
9
36
4
10
22
5
15
1
23
2
232
194
181
93
35
101
32
24
117
12
41
4
84
12
930
Total
24
224
225
220
213
215
210
Ryan King
205
John Scapillato
200
196
196
Kristen Goering
Justin Smith
195
190
185
180
Dec06-02 Team
Figure 11.1-1 Actual Team Effort to Date
Tables 11.1-3
and Table 11.1-4 show the original and updated resources required for the
project.
Table 11.1-3 - Other Resource Requirements
(Original)
Equipment and Other Resources
Team
Item
hours
Cost
Motherboard/Processor 1
0
$150.00
RAM 1
0
$50.00
Storage 1
0
$200.00
Motherboard/Processor 2
RAM 2
0
0
$150.00
$50.00
Storage 2
0
$200.00
LCD
0
$75.00
Keypad
0
$100.00
Misc. Buttons
0
$50.00
Printer Controller
Ethernet Switch
0
0
$120.00
$57.00
UPS Battery Backup Unit
0
$100.00
Housing
0
$0.00
Project Poster
10
$50.00
Total
10
$1,352.00
25
Table 11.1-4 - Other Resource Requirements
(Updated)
Equipment and Other Resources
Team
Item
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
UPS Battery Backup Unit
0
$100.00
XP
Embedded
Run
Time
License
0
$79.00
Housing
0
$0.00
Project Poster
10
$50.00
Total
10
$1,051.00
give the original and revised financial resources required for
the project. Estimates for labor are also included in the tables. Cost of labor is estimated
at $11.00/hour.
Table 11.1-5 and Table 11.1-6
Table 11.1-5: Financial Requirements (original)
Cost
w/o Cost
Item
labor
labor
Parts and Materials
Motherboard/Processor 1
$150.00
$150.00
RAM 1
$50.00
$50.00
Storage 1
$200.00
$200.00
Motherboard/Processor 2
$150.00
$150.00
RAM 2
$50.00
$50.00
Storage 2
$200.00
$200.00
LCD
$75.00
$75.00
Keypad
$100.00
$100.00
Misc. Buttons
$50.00
$50.00
Printer Interface
$120.00
$120.00
Ethernet Switch
$57.00
$57.00
UPS Battery Backup Unit
$100.00
$100.00
Housing
$100.00
$100.00
Project Poster
$50.00
$50.00
Services
Shipping and Handling
$50.00
$50.00
w/
26
Binding
Equipment subtotal (per unit)
Labor ($11 per hour)
Ryan King
Kristen Goering
Justin Smith
John Scapillato
Labor Subtotal
Project Total
$30.00
$1,532.00
$30.00
$1,532.00
$2,365.00
$2,321.00
$2,310.00
$2,343.00
$9,339.00
$10,871.00
Table 11.1-6: Financial Requirements (updated)
Cost
w/o Cost
w/
Item
labor
labor
Parts and Materials
Motherboard/Processor 1
$150.00
$150.00
RAM 1
$50.00
$50.00
Storage 1
$200.00
$200.00
Motherboard/Processor 2
$150.00
$150.00
RAM 2
$50.00
$50.00
Storage 2
$200.00
$200.00
LCD
$75.00
$75.00
Keypad
$100.00
$100.00
Misc. Buttons
$50.00
$50.00
Printer Interface
$120.00
$120.00
Ethernet Switch
$57.00
$57.00
UPS Battery Backup Unit
$100.00
$100.00
Housing
$100.00
$100.00
Project Poster
$50.00
$50.00
XP Embedded License
$79.00
$79.00
Shipping and Handling
$50.00
$50.00
Binding
$30.00
$30.00
Equipment subtotal (per unit) $1111.00
$1111.00
Labor ($11 per hour)
Ryan King
$2,596.00
Kristen Goering
$2,508.00
Justin Smith
$2,552.00
John Scapillato
$2,574.00
Labor Subtotal
$10,230.00
27
11.2 Schedules
shows the Gantt chart which illustrates the project schedule and deliverables.
The blue lines are the original schedule estimates, the red lines are the revised schedule
estimates, and the green lines are the team’s actual final project schedule.
Figure 11.2-1
Figure 11.2-1 Dates Deliverable Schedule
12. Project Evaluation
This section describes the project objectives and assesses whether or not, and to what
level, they have been met.
28

Project Familiarization
The familiarization phase of this project has been completed and fully met. The
project team worked hard during its first semester to become familiar with the
requirements of the project and functional details of the software through the
team’s efforts executing test cases. This semester required further familiarization
with the code and hardware.

Laptop update system
The laptop update system has not been completed and is still in the preliminary
design phases.

Testing of Current Unit
The primary testing of the current unit has been completed and secondary testing
has begun on both the hardware and software. However, on-site testing has yet to
take place with the possibility of software changes to fix bugs, meaning that there
is more effort in this task that must take place before the project is finished. The
team’s preparation efforts included fixing any software bugs that were found and
setting up the unit parameters correctly after reinstalling components such as
Windows XP Embedded. This task is approximately 90% complete and is
expected to be 100% complete by the end of the semester.

Preparation and Installation of Unit
The preparation and installation milestone of this project has been partially
completed. After completing the creation of a fully licensed image of Windows
XP Embedded it is nearly ready for install. Installation will be done by an ISU
facilities team, and that is expected to take place in the beginning of the Spring
2007 semester, meaning the team projects this task to be completed successfully
by the end of the semester.

Support Unit
Although the opportunity to fully support the unit on-site has not arisen, efforts
have been made to create a system to contact team members and have any errors
fixed in a short time. The error reporting forms to describe the actual incident
leading to the error have been created, as well as the forms for the solutions. As it
currently stands, this milestone is complete.

Build Second Unit
Building of the second unit has been partially completed. As the Windows XP
Embedded licensing issue has put off the installation of the original unit, the
complete assembly of the second unit has not taken the priority originally
expected. However, assembly of the parts has begun. This milestone is about
25% complete and the remainder of it will fall mostly on the May07-02 team.
29

Parking Meter Simulation System
Parking meter simulation system has been mostly completed. Parts for the
simulation system were ordered at the same time as parts for the second unit and
were received at the same time causing some slight delays. However, assembly
of the simulation system has begun and is about 20% complete. Again like the
second unit the completion of this milestone will fall mostly on the May07-02
team.

Documentation and Reporting
Documentation and reporting of the project has been proceeding at a very fast
pace as delays with parts and Windows XP Embedded licenses have given the
team ample time to work on it. Work on the reediting of the software functional
description has begun and soft copies of documents that were originally hand
written have been created. This milestone is approximately 50% complete with
more work expected in the remaining weeks of the semester. Hard copies of all
necessary documents should be completed by the end of the semester.

Overall Evaluation
With the criteria of “great success”, “success”, and “not a success,” the team has
dubbed this project a “success”. The team has not completely reached all of our
milestones, but the team has made progress and has mostly met its objectives,
with expected further progress yet this semester. Difficulties caused by the
Windows XP Embedded licensing issue have been the reason the team has not
gotten the unit out for testing, as well as the recent power surges. The current
team inherited these problems, and must bear responsibility for the difficulties and
lost time it has caused the team. These delays ultimately reflect on the team’s
performance, but we believe this project to still have been a “success” due to the
team’s good performance on other objectives and excellent team work.
13. Commercialization
Factors affecting the commercialization and mass production of the parking meter are:
 Cost of the product
 Retail price of the product
 Potential market for the product
The potential market for this product would include large universities like Iowa State as
well as large cities with parking problems. This product would cut back on the cost of
large parking structures and prevent the need for a large number of parking employees.
14. Recommendations for Additional Work
Future prototype parking meter teams will still be needed to implement the following:
30

Continued Implementation
Future prototype parking meter teams will have a few more activities to
accomplish. They must provide continuing and effective support of the new
parking meter system once it is installed in the Armory parking lot. They must
also continue to build a second parking meter slave unit, and develop a simulation
system capable of debugging and solving problems from the parking meter lab.
Lastly, a major activity will be to develop a method of loading software fixes and
changes to the parking meter system by linking a laptop to the parking meter
units.

Commercialization
This product is designed for the ISU Parking Division, but upon its successful
onsite testing could be much more widely used. Upon the successful completion
of the second unit and proof of the networkability of the units, it would be easy to
mass produce these units and commercialize them to other universities, city and
state governments, and commercial parking companies.
15. Lessons Learned
This section will outline what the team has learned from this project. It goes into detail
about what did and did not go well, the knowledge the team has gained, and any changes
the team would make if it had to do the project over.

What Went Well
Despite the schedule delays, the team was able to work hard to get most of the
deliverables completed. Every member took the lead to get certain tasks done, and
contributed equally to the project.

What Did Not Go Well
There were a few things in this project that did not go well. The major issue the
team encountered was the delay experienced in properly installing the XP
Embedded runtime license and rebuilding the software image. Once this was
completed the team was able to move forward with the project until power surges
surfaced as a problem.

Knowledge Gained
The experience the team gained from this project contained elements of both
technical and non-technical knowledge. In the area of technical knowledge, the
team gained a better understanding of the software requirements and
implementing them, as well as experience using Microsoft Project, Microsoft
Visual Studio .NET, Windows XP Embedded, Linux, C++, and MySQL. Also, a
wealth of testing knowledge was gained. All of these are important in a real
world corporate environment. Non-technical knowledge obtained included time
management, working in a team environment, designing a poster, writing
31
technical documents, working with a system that is pre-existing, and reading
documentation from other teams.

Things To Change
In hindsight, previous teams’ documentation was found to be incomplete or nonexistent. Stricter guidelines should have been implemented to ensure the proper
documentation is created for future teams and users. Communications between
previous teams was also poor, and this team attempted to correct this problem
with the incoming May07-02 team.
16. Risk Management
This section will discuss risks that the project team planned for and encountered, and it’s
success in dealing with them.
16.1 Anticipated Risks
The team identified a number of potential risks listed below:

Loss Of Team Member
The team planned for potentially losing a team member by communicating well
with one another and making certain everyone was well involved. The team
usually assigned multiple team members to each task to make sure there was not a
knowledge imbalance on the team. The team also has used its members’
notebooks to write down notes that could be recovered in the case that a team
member was lost. In addition, all documentation and source code was stored in a
location accessible to all team members.

Hardware Failure
To plan for the risk of hardware failure, the team has had the list of parts close at
hand to quickly order new hardware and made sure that all members were
informed of any hardware changes.

Parts Procurement Delays
The team planned for parts taking longer than expected to arrive. This was done
by being sure to place the parts order far ahead of the time that the team would
actually need the parts.

Data Loss
Data loss is another risk the team anticipated. The team has used a source control
system to keep multiple versions of the parking meter software code, as well as
having multiple electronic copies of the code and all documentation.
32
16.2 Anticipated Risks Encountered
Certain risks that were anticipated were in fact encountered in the project.

Hardware Failure
One problem the team encountered was a broken connector on the LCD unit.
Looking closely at the product details allowed the team to see how it could be
fixed, and the team forwarded that responsibility to the proper expertise quickly.
Also, a power surge has recently caused a couple of the Disk On Chips to fail.
New chips were ordered and will replace the old DOCs once the cause of the
power surges are discovered.
16.3 Unanticipated Risks Encountered
This project faced a couple unanticipated risks that greatly affected the progress of the
project.
16.3.1 Windows XP Embedded Licensing and Power Surge.
The major issue the team encountered was properly installing XP Embedded and
rebuilding the software image. Once the runtime license was was properly installed and
the image built, the team was able to move forward with the project until power surges
surfaced as a problem. The team is currently working hard to discover the cause of these
power surges and will be able to further progress with the project once the cause is
unveiled.
16.4 Resultant Changes
Due to the unanticipated risk the team encountered, the team has made changes to its
management of risks. The team has since carefully reviewed many of the processes that
will make the parking meter system work, such as the installation of all components and
software to make sure there are no other latent issues that the team is unaware of because
of miscommunication between project teams. This has been successful in working out
issues with building and installing the final parking meter software.
17. Project Team Information
This section includes information about the client, faculty advisors and student team
members of this project.
33
Client
Doug Houghton
Captain
Department of Public Safety
31 Armory Building
Ames, IA 50011
Vox: 515-294-1987
Fax: 515-294-0383
dad@iastate.edu
Faculty Advisors
Dr. John Lamont Professor
324 Town Engineering
Iowa State University
Ames, IA 50010
Vox: 515-294-3600
jwlamont@iastate.edu
Ralph Patterson III
326 Town Engineering
Iowa State University
Ames, IA 50010
Vox: 515-294-2428
repiii@iastate.edu
Team Members
Ryan King
Computer Engineering
6138 Frederiksen Ct.
Ames, IA 50010
515-419-2902
kingbob@iastate.edu
Justin Smith
Computer Engineering
200 Stanton #502
Ames, IA 50014
515-598-9393
jmsmith@iastate.edu
Kristen Goering
Electrical Engineering
4915 Todd Ave. #4
Ames, IA 50014
515-238-6753
goering1@iastate.edu
John Scapillato
Electrical Engineering
PO Box 2413
Ames, IA 50010
515-232-5533
jscapill@iastate.edu
18. Closing Summary
This project attacks a very real problem faced by the administration at Iowa State
University. Parking space is a problem that has been faced in an increasing measure over
the last few years, and attempts to provide and monitor parking by building lots with
multiple stall parking meters have led to problems for the ISU Parking Division. This
project provides a solution to the parking meter issue by implementing at a low cost the
features that the Parking Division has specified necessary to provide flexible and efficient
parking regulation enforcement. Being developed for easy replication, this project will
34
allow the Parking Division the expansion in its parking enforcement it needs for the
future, with the ability to install the parking meter unit in new parking lots.
This project has been continuing for a time, and in that time it has seen successes and
failures, both before this team became a part of the project and since the time it has been
on it. Though it has progressed slower than the team have expected due to a software
licensing issue, the team has taken much care to test and fix the software of the unit,
steering the project in the right direction and allowing it to be finished as a robust product
that will work well at meeting the requirements that the ISU Parking Division has for it.
19. References
Prototype Parking Meter – Phase 4 Project Plan – Dec05-02
March 6, 2005
From: http://seniord.ece.iastate.edu/dec0502/plan/project_plan.pdf
Prototype Parking Meter – Phase 3 Project Plan – May05-02
September 30, 2004
From: http://seniord.ee.iastate.edu/may0502/ProjectPlan.pdf
Software Functional Description – Dec04-02, J. Lamont and R. Patterson III
July 19, 2004
Prototype Parking Meter – Phase 4 Final Report – Dec05-02
December 14, 2005
From: http://seniord.ece.iastate.edu/dec0502/bound%20final%20report.doc
Prototype Parking Meter – Phase 5 Final Report – May06-02
35
May 5, 2005
From: http://seniord.ece.iastate.edu/may0602/docs.html
36