Prototype Parking Meter � Phase 4 by Wi6r8Piv


									             Prototype Parking Meter – Phase 6
                                           Design Report

                                   Project team: Dec06-02

                      Iowa State University Parking Division

                      John W. Lamont, Ralph E. Patterson III

                                     Team Members
                               Ryan King, Kristen Goering
                               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.

                                             April 1, 2006
                           Table of Contents
Item                                               Page

Table of Contents                                  i
List of Figures                                    ii
List of Tables                                     iii
List of Definitions                                iv-v
Executive Summary                                  1
Acknowledgement                                    2
1. Problem Statement                               2-3
        1.1. General Problem Statement             2
        1.2. General Solution Approach             3
2. Operating Environment                           4
3. Intended Users                                  4
4. Intended Uses                                   4
5. Assumptions                                     5
6. Limitations                                     5
7. Expected End Result and Other Deliverables      5-7
8. Project Accomplishments and Current Status      7-8
        8.1 Previous Accomplishments               7
        8.2 Present Accomplishments                8
        8.3 Required Future Activities             8
9. Approach Used                                   8-14
        9.1 Design Objectives                      8-9
        9.2 Functional Requirements                9-11
        9.3 Constraint Considerations              11-12
        9.4 Technical Approach Considerations      12-13
        9.5 Testing Approach Considerations        13-14
        9.6 Project Continuation Recommendations   14
10. Detailed Design                                14-19
11. Estimated Resources and Schedules              19-26
        11.1 Estimated Resources                   19-23
        11.2 Schedules                             24-26
12. Project Team Information                       27
13. Closing Summary                                28
14. References                                     29

List of Figures
Item                                                        Page

Figure 1 – Current Parking Meter System                     2
Figure 2 – Parking Meter Support Request Form               10
Figure 3 – Parking Meter Support Solutions Form             11
Figure 4 – Slave Unit Hardware Block Diagram                15
Figure 5 – Flowchart for Customer Functions Software        18
Figure 6 – Flowchart for Administrator Functions Software   19
Figure 7 – Project Schedule                                 24
Figure 8 – Project Schedule Revised                         25
Figure 9 – Deliverables Schedule (Original and Revised)     26

List of Tables
Item                                                Page

Table 1 – Personnel Effort Requirements             20
Table 2 – Personnel Effort Requirements (Updated)   20
Table 3 – Other Resource Requirements (Original)    21
Table 4 – Other Resource Requirements (Updated)     21
Table 5 – Financial Requirements                    22
Table 6 – Financial Requirements (Updated)          23

List of Definitions

802.11: The standard set of protocols for wireless Ethernet communications. 802.11b,
       802.11g, and 802.11i are common standards in use today.

AC: Alternating current, the form of electrical power most commonly used in the United

C++: An object-oriented programming language that is popular for its ease of use and

Dec05-02: The current project team.

DPS: The Department of Public Safety, the entity responsible for all aspects of security
      on the Iowa State University campus.

Ethernet: The current standard for high-speed computer-to-computer communications.

Gantt chart: a chart indicating the schedule for a project.

Linux: An open-source operating system.

MySQL: An open-source database system used on Linux.

List of Definitions (cont.)
PCB: Printed circuit board. A PCB contains an electrical circuit in a compact form

SFD: Software functional description. A document formally defining the functionality of
      a piece of software.

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).

x86: The dominant processor architecture on the market today.

Executive Summary

The parking situation has become less of a problem in recent years. With enrollment and
staff numbers decreasing, the need for new parking spaces has become less. However,
the need to better control and keep track of the existing parking lots has become more of
a concern. Currently the Department of Public Safety had pre-pay parking lots that are
regulated by automated parking meters which were purchased from a company that is no
longer in existence. Because of this senior design teams have taken on a project to create
their own system that will not only have more functionality than the current systems, but
will also be cheaper.

The project that is in development will consist of a dual processor system that will ensure
that data will not be lost in the event that one processor fails. Along with the dual
processor master there will also be a single processor “slave.” The slave will gather the
input from the user and the master will output to the slave what the users want to know.
All of these parts will be stored in what will be referred to as the primary unit. There will
also be secondary units that only contain the slave processor, but will still communicate
with the master via Ethernet.

The system hardware and software for the primary unit has been completed and is in the
testing phase. The testing phase consists of many different sub-phases. First, all the
hardware had to be tested separate from the system. This has been completed. Then the
software was tested using a simulator system. The simulator acts just as any of the units
will therefore, it is very convenient way to ensure the software will work on the unit.
After the hardware and software had been tested separately, they needed to be tested
together. This is where the testing phase currently stands. The hardware has all been
assembled in the unit’s case and the software has been loaded. The testing that remains
to be done will be the same testing that was performed for the simulator, but it will be
done by the intended users which are outlined in the following document.

This document will also go into more specific detail about what the parking meter
system is intended to do. Along with a problem description, this document will outline
the specifics on how the units were built and the schedules that the teams kept. The
testing of the units is outlined in detail as well as extended support. This includes who
will be responsible for supporting the unit upon installation in the armory parking lot,
and how the DPS will notify the teams of problems .

The project is beginning to take shape and the unit should be installed before the end of
the semester. However, there is still enough work to continue adding teams to the project.
A laptop update system must be designed to make updating the software in the units
easier. Also, the City of Ames has expressed interest in the project so more teams will be
required to ensure the requests of new clients can be addressed.


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,
and 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

1. 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.
                                                       Figure 1: Current parking meter system

1.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
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.

1.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, and easier to maintain.

The parking meter system in development will 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 also 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 new parking meter units will also be much more cost effective. The current units
start at $10,000 and quickly move upwards of $75,000 as functionality is added. The
parking meter system that is in development has an estimated cost of $1,500 before labor.

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
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 fourth group, Dec05-02, was responsible for testing the prototype unit, and
producing a parts list and assembly/setup instructions. The May06-02 team designed an
instructional sign to assist users of the parking meter, created a user’s manual for DPS,
and rewrote the test cases to account for the new standardized rates given by DPS. Both
the Dec06-02 team and the May06-02 team 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. Dec06-02 team will
also be responsible for the design and implementation of a laptop updating system to be
used by DPS.

2. 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.

3. Intended Users

There are three classes of users will use the system:

First class:
     College students at Iowa State University.
     Faculty and staff of Iowa Sate University
     Visitors to the Iowa State University campus

Second class:
    The Iowa State University Department of Public Safety student employees. They
      need additional functionality in order to monitor the parking lots.

Third class:
    The Administrator. This user, a permanent DPS employee, will have access to all
       the features available to supervisor class.

4. 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: specifying an amount of time, inserting
        money, or specifying an ending time.
    Allow time to be added to any parking space from any unit in lot or on campus.
    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 Administrator, the system will:
    Allow DPS to change hourly rates and set holidays.
    Allow users to add and delete first and second class users.

5. Assumptions

The list below is all the assumptions that the group are talking 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

6. Limitations

The list below is all the limitations that the group are talking 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.
     The servers unit must consist of two redundant processors with automatic failure
     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
     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.

7. Expected End Product and Other Deliverables

The end product of this project will be a prototype multi-space parking meter system, a
DPS user manual, a technical specification, a laptop updating system, an in office
simulator, a project plan, a design report, and a final report. These items are detailed on
the following page.

   Multi-space parking meter system
           This system will consist of a set of units, and will be capable of handling
           up to 1000 parking spaces. The master unit will store all of the parking lot
           information, including rates and activity. The slave unit(s) will retrieve
           this information and act as the interface from which parking time is
           purchased. The system will allow patrons of the lot to pay for parking,
           and allow DPS to monitor the usage and enforcement of the parking lot.

   DPS User Manual
         The DPS user manual will be a document that describes the operation of
         the machines in a non-technical manner so that DPS officers know how to
         use them. The operations described in the manual will include monitoring
         occupancy, making rate changes, and performing other enforcement

   Technical Specification
           The technical specification document will be a document describing the
           technical specifications of both the hardware and software running on the
           master and slave units. The document is not designed for common users,
           but instead as a resource for future designers and maintenance of this

   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.

   In Office Simulator
            This simulator will remain on a desktop PC within DPS offices so a
            technician may work on software issues without having to be at the
            outside unit. The May06-02 team designed a simulator which the Dec06-
            02 team will continue to test.

   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.

   Design Report
           The design report will be 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 will be delivered in
           March of 2006.

   Final Report
           The final report will be a document that provides the most complete
           description of the project along with the record of its development. It will
           contain all aspects of the project, from the background development to the
              testing to the end product description. This document will also provide
              suggestions for future work on the project. This document will be
              delivered in December of 2006.

8. Project Accomplishments and Current Status

This section reviews the accomplishments made by previous project teams and the future
achievements expected from the Dec06-02 team.

8.1 Previous Accomplishments

Below is a list of the accomplishments that have been made since the project’s beginning
in May 2003.

Fall 2003 - Spring 2004
    Created a complete problem definition containing uses, assumptions, limitations,
       functional requirements, management procedures, and success evaluation criteria.
    Researched hardware and software to meet the project functional requirements.

Spring 2004 – Fall 2004
    Selected hardware and software for the project implementation.
    Completed the project design.
    Defined a functioning product that would meet the design requirements,
      specifications and client needs.

Fall 2004 - Spring 2005
    Completed user interface flowcharts.
    Completed creation, customization and installation of Windows XP Embedded to
       the slave computer’s storage device.
    Completed the software classes and functional description.
    Implemented software classes.
    Installed and configured SQL database for master units.
    Performed basic customer testing and bug fixing.

Spring 2005 – Fall 2005
    Completed a parts list and assembly/setup instructions.
    Wrote a formal test plan and executed test cases.
    Resolved code problems and hardware issues.

Fall 2005 – Spring 2006
    Spot-tested the system to check for major faults or unresolved issues.
    Modified the user interface to increase user friendliness.
    Verified the server back-up functionality.
    Verified that the hardware components would meet the specified requirements
       and perform under the specified conditions.
    Wrote user instructions to be read by the customers using the system.

8.2 Present Accomplishments

In conjunction with the May06-02 team, the following accomplishments have been
achieved during the Spring 2006 semester.

      Ordered parts for the second slave unit.
      Received license for XP Embedded and installed it on the boards in the unit.
      Replaced the internal heater of the unit using a light bulb rather than a heater strip.
      Redesigned the wiring from the thermostat to the heater
      Secured internal parts of the unit.
      Began the design of the laptop updating system.
      Beta tested hardware and software of the completed unit.

8.3 Required Future Activities

The following activities have yet to be accomplished for this project.

      Install the master unit in the Armory parking lot.
      Assemble a second slave unit to be placed in the Armory parking lot.
      Assemble a testing unit for use in the lab.
      Write the technical specification document.
      Provide on-site support for the installed units.
      Implement a laptop updating system.
      Get a second cabinet for the second slave

9. Approach Used

The Dec06-02 team will use the following approach.

9.1 Design Objectives

These design objectives have been formed in response to the overall problem statement.
They will guide us in our designing of a solution.

      Technical Specification
       Upon final completion of assembly of the units, it is essential that a document be
       created to define the assembly, set-up, and installation instructions needed to
       recreate a functional master or slave unit.

      Second Slave Unit
       The second slave unit will perform identically to the primary unit in hardware,
       software functionality and user (customer/administrator/supervisor) interfaces. A
       parts inventory must be completed so that the hardware for the second slave is
       identical to the first unit.
      Laptop Updating System
       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.

9.2 Functional Requirements

The following functions shall be required to successfully complete the project.

      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

      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 (sample form can be seen on pages 10 and 11). 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.

Figure 2: Parking Meter Support Request Form

Figure 3: Parking Meter Support Solutions Form

9.3 Constraints Considerations

The entire project shall run 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 120 V AC power, as well as
       have the ability to run off of battery backup in case of main power failure.

      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.

9.4 Technical Approach Considerations

Most of the technical approach considerations have already been addressed, as the master
and slave units have finished development. The specific technical considerations at this
stage of the project will be in how to support the unit, how to replicate it, how to develop
simulation capability, and how to update the unit via laptop.

The master unit is a dual-processor redundant server unit with automatic failure
protection, 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. The
master unit will have the database information about the lot stored on it. Storing the
database on the redundant unit will ensure that the information will not be lost.

The slave units are single processor units. They must support the user interface
peripherals: coin acceptor, printer, keypad, and LCD screen. The slave units will have
the software package that runs the interface between the user, the hardware, and the

The master and slave units will communicate through software that has been previously
designed to query the database. The master unit will have this software on it. The client
unit will have software on it to interpret the signals from the hardware, and pass them
along to the software on the master unit. The software on the master will then query the
databases and pass the information back to the slave unit. From there the slave unit will
pass the information to the hardware and thusly to the user.

The software package must be robust and feature-filled. C++ will be used to implement
this package. For the slave, the development environment will be Windows XP
Embedded Operating System. XP Embedded was chosen because it takes up less space
and does not have the multimedia functionality that XP has. The multimedia
functionality will not be needed and therefore does not need to take up the limited space
on the boards. For the master, Debian Linux will be used. The database system, located in
the master unit, will use MySQL, offering cross-platform compatibility between the
master and slave. The task of keeping the databases redundant will fall to the utility Ultra

Future work must continue based upon these previously decided technical approaches.
The slave unit will be replicated from the bill of materials and assembly/setup
instructions already developed and reviewed by the Dec05-02 team and May06-02 team.

Simulation capability will mirror the technical implementation of the existing system so it
can be used as an effective debugging tool.

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.

A second exterior case will need to be developed for the second unit. This case will not
need to be exactly like the case used for the primary unit. This freedom comes from the
need to modify the case so that mounting the different components is easier. It does,
however, need to be identical on the outside so that the users will not be confused.

9.5 Testing Approach Considerations

The following is a definition of the methodologies and acceptance criteria to be used in
the testing of the intermediate and end-products resulting from this product.

      Software testing
       Software has been installed, and tested to ensure proper operation. The software
       was tested against existing implementations to ensure uniform operation between
       units. The software was tested on a simulator with out the actual unit present.

      Hardware testing
       The unit will require thorough testing upon completion. Tests have been
       conducted to verify that the individual components were functioning as well as
       the unit as a whole. For example, the team tested the coin acceptor to make sure it
       accepted and registered coins.. Testing was completed by as many subjects as
       possible, including all Dec05-02, May06-02 and Dec06-02 group members. Each
       test was performed and documented with a PASS/FAIL that ensured timely fixing
       of any problems that were encountered.

      Field Testing
       This team will assist the May06-02 team in the testing that must occur before the
       system is permanently placed in the parking area, and before the design has been

       replicated. This will include placing the unit in a parking area for a designated
       amount of time to obtain non-simulated information from intended users. This
       will allow the team(s) to quickly make any changes that need to be made due to
       problems with the unit, and added requests made by DPS. A set of defined test
       cases will be used to test all user interfaces, boundary conditions, and extreme
       cases. These test cases will be the same tests performed on the software and
       hardware that was collectively designed by DPS and the previous design teams.

      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.

9.6 Project Continuation Recommendations

The Dec06-02 team believes the project continues to be feasible and is progressing well
toward meeting the objectives set in the project problem statement. Also, multiple
semesters of work have been put into it, with a testable product ready. The team’s
recommendation is to continue the project based on the current design. The current team
also believes there is enough work for a May. ‘07 team to begin in the spring. Continued
support and testing, laptop integration, updating the software functional document, and
other potential features that DPS may decide are necessary will provide enough work for
another team next school year. As support for both of the units to be installed in the
Armory parking lot is essential and the possibility that these meters may be deployed in
further, we feel it is essential that another team continue the project. The Dec06-02 team
looks forward to working with this team in the spring.

10. Detailed Design

This section describes the detailed design that will be followed to construct the second
prototype parking meter and the laptop updating system. Since the same server will be
used to support multiple prototype parking meters, the slave unit is the only portion of the
system that must be duplicated. Below (Figure 2) is a block diagram of the hardware
design of this system which is used for user interaction.

Figure 4: Slave unit hardware block diagram

The specific parts required for the slave unit are listed below along with their purchase
location and price.

Via Epia 800 MHz motherboard
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
Cost: $128.00
Notes: This was just an affordable option. Any mini ITX case will do.

Crucial 256 MB PC133 RAM
Cost: $40.00
Notes: Any ram will do.

LCD Module
Matrix Orbital LCD4041
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
Cost: $100.00
Notes: Serves as the Hard disk. No moving parts and it uses an IDE interface.

StacoSwitch M151XX05
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
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).

Coin Acceptor Controller
Upstate Networks Incorporated MDB2PC
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
Cost: $9.73
Notes: Any 4.88 X 6.88 X 1.5 or similar enclosure will do.

Thermal Printer
Fujitsu FTP-639MCL
Cost: approx. $350.00
Notes: Connects to the client via USB. Drivers are located at

Coin and Printer Power Supply
Infinite Peripherals SPU-230-24IP
AC power in 24VDC power out
Cost: $69.00
Notes: Dual power supply provides power for both the printer and the coin acceptor /
controller card.

Battery Backup (UPS)
Price: $80.00
Notes: This model was selected because of dimensions, but any UPS will do.

Outer Case
Source: Manufactured by ME students
Price: Unknown

Windows XP Embedded Run Time License
Price: $79

Source: DPS or Computer User’s Group
Price: $0

Figure 5: Flowchart for customer functions software
(Note: Revising chart to make readable, it is the only documentation available at this time)

Figure 6: Flowchart for administrator functions software
(Note: Revising chart to make readable, it is the only documentation available at this time)

11. Estimated Resources and Schedules

This section describes an estimate of the resources required to complete this project.

11.1 Estimated Resources

Table 2 shows the projected team member effort for the following tasks:
    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
    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 1: Personnel effort requirements (original)
Table 1 - Personnel Effort Requirements
             Task   Task    Task   Task    Task      Task 6            Task 7      Task 8
Name                                                                                                 Total
             1      2       3      4       5
                                                     6.1   6.2   6.3   7.1   7.2   8.1   8.2   8.3
King         36     40      18     6       40        6     8     24    4     12    0     20    1     215
Scapillato   40     50      21     0       10        10    4     35    2     6     3     25    5     211
Goering      37     52      20     7       15        12    2     36    1     8     0     16    4     210
Smith        32     39      19     5       36        4     10    22    5     15    1     23    2     213
Total        145    181     78     18      101       32    24    117   12    41    4     84    12    849

Table 2: Personnel effort requirements (updated)
Table 2 - Personnel Effort Requirements
             Task   Task    Task   Task    Task      Task 6            Task 7      Task 8
Name                                                                                                 Total
             1      2       3      4       5
                                                     6.1   6.2   6.3   7.1   7.2   8.1   8.2   8.3
King         46     40      25     10      40        6     8     24    4     12    0     20    1     236
Scapillato   52     50      24     8       10        10    4     35    2     6     3     25    5     234
Goering      51     52      23     8       15        12    2     36    1     8     0     16    4     228
Smith        45     39      21     9       36        4     10    22    5     15    1     23    2     232
Total        194    181     93     35      101       32    24    117   12    41    4     84    12    930

The updated personnel effort requirements (from Table 1 to Table 2) reflect the actual time
spent to date on our completed Tasks 1, 3, and 4. The hours for the remaining tasks did
not change, as we feel they are still accurate estimates of future effort. The hours spent
on Task 1 (project familiarization) increased because more time was needed to fully
familiarize the team with the project. Tasks 3 and 4 increased due to unforeseen

Table 3: Other resource requirements (original)
 Table 3 - Other Resource Requirements (Original)
 Equipment and Other Resources
 Item                    hours                         Cost
 Motherboard/Processor 1             0                 $150.00
 RAM 1                               0                 $50.00
 Storage 1                           0                 $200.00
 Motherboard/Processor 2             0                 $150.00
 RAM 2                               0                 $50.00
 Storage 2                           0                 $200.00
 LCD                                 0                 $75.00
 Keypad                              0                 $100.00
 Misc. Buttons                       0                 $50.00
 Printer Controller                  0                 $120.00
 Ethernet Switch                     0                 $57.00
 UPS Battery Backup Unit             0                 $100.00
 Housing                             0                 $0.00
 Project Poster                      10                $50.00
 Total                               10                $1,352.00

Table 4: Other resource requirements (updated)
 Table 4 - Other Resource Requirements (Updated)
 Equipment and Other Resources
 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

Tables 3 and 4 summarize the original and revised financial resources required for this
project. The updated requirements reflect the parts necessary for building a single slave
unit only, and the additional cost of obtaining a Windows XP Embedded run time license.

Table 5: Financial Requirements
Table 5: Financial Requirements
                               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
Shipping and Handling          $50.00         $50.00
Binding                        $30.00         $30.00
Equipment subtotal (per unit) $1,532.00       $1,532.00
Labor ($11 per hour)
Ryan King                                     $2,365.00
Kristen Goering                               $2,321.00
Justin Smith                                  $2,310.00
John Scapillato                               $2,343.00
Labor Subtotal                                $9,339.00
Project Total                                 $10,871.00

Table 6: Financial Requirements (Updated)
Table 6: Financial Requirements
                               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
Project Total                                   $11,341.00

The changes between Tables 5 and 6 reflect the additional cost of labor and the Windows
XP Embedded license that was needed for the project.

11.2 Schedules

Figures 5 and 6 show Gantt charts included to illustrate the project schedule and
deliverables. The project schedule is dependant on collaboration with the May06-02
team. The gray shaded areas indicated breaks and holidays where work will not be

 Figure 7: Project Schedule

Figure   8:   Project    Schedule   Revised

Figure   9:   Deliverables   Schedule   (Original   and   Revised)

12. Project Team Information

This section outlines the people involved in the Dec06-02 phase of the Parking Meter

Doug Houghton
Department of Public Safety
31 Armory Building
Ames, IA 50011
Vox: 515-294-1987
Fax: 515-294-0383

Faculty Advisors
Dr. John Lamont Professor                         Ralph Patterson III
324 Town Engineering                             326 Town Engineering
Iowa State University                            Iowa State University
Ames, IA 50010                                   Ames, IA 50010
Vox: 515-294-3600                                Vox: 515-294-2428                   

Team Members
Ryan King                                        Justin Smith
Computer Engineering                             Computer Engineering
6138 Frederiksen Ct.                             200 Stanton #502
Ames, IA 50010                                   Ames, IA 50014
515-419-2902                                     515-598-9393                    

Kristen Goering                                  John Scapillato
Electrical Engineering                           Electrical Engineering
4915 Todd Ave. #4                                PO Box 2413
Ames, IA 50014                                   Ames, IA 50010
515-238-6753                                     515-232-5533                   

13. Closing Summary

Parking has become an important challenge lately in urban centers and universities, as
there is an increasingly high demand for parking resources. As an effect of this, there is
always a need to be able to better track and control the parking structures around the
campus and city. This will be accomplished by continuing the construction of centralized
parking meter systems; saving extra time and money from being spent on a commercial
parking meter solution that does not meet the University’s needs. This multi-stall parking
meter system is flexible and architecturally simple, allowing maintenance to be done at
the University. Making multiple units will enable the University to better keep track of
their parking and maybe even enable expansion of the system into the City of Ames and
beyond. The main function of the team will be to ensure that the units work and that
there is plenty of support available to keep them working. With this system in place, the
parking situation on campus will only become easier for law enforcement and users to
keep tabs on.

14. References

Prototype Parking Meter – Phase 5 Design Report – May06-02
November 8, 2005

Prototype Parking Meter – Phase 5 Project Plan – May06-02
September 30, 2005

Prototype Parking Meter – Phase 4 Project Plan – Dec05-02
March 6, 2005

Prototype Parking Meter – Phase 3 Project Plan – May05-02
September 30, 2004

Software Functional Description – Dec04-02, J. Lamont and R. Patterson III
July 19, 2004


To top