Prototype Parking Metering System—Phase 2

Design Report

DEC 04-02

Client Doug Houghton

Captain Department of Public Safety

Iowa State University

Advisors Dr. John Lamont, EE/CprE

Prof. Ralph Patterson III, EE/CprE

Team Members Joe Reinsma

John Goldbach Andrew Ross Mikel Bezdek Irsan Halim

REPORT DISCLAIMER NOTICE

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.

6 April 2004

Table of Contents List of Figures ii List of Tables iii List of Symbols and Definitions iv 1. Introductory Materials 1 1.1. Abstract 1 1.2. Acknowledgement 1 1.3. Problem Statement 1 1.3.1. General Problem Statement 1 1.3.2. General Solution Approach 2 1.4. Operating Environment 2 1.5. Intended Users and Uses 2 1.5.1. Users 3 1.5.2. Uses 3 1.6. Assumptions and Limitations 3 1.6.1. Assumptions 3 1.6.2. Limitations 4 1.7. Expected End Product and Other Deliverables 4 2. Approach and Product Design Results 6 2.1. Proposed Approach 6 2.1.1. Design Objectives 6 2.1.2. Functional Requirements 6 2.1.3. Design Constraints 7 2.1.4. Technical Approach Considerations and Results 8 2.2. Testing Approach Considerations 9 2.2.1. Hardware Testing 9 2.2.2. Software Testing 9 2.2.3. System Prototype Testing 10 2.3. Recommendations for Project Continuation or Modification 10 2.4. Detailed Design 10 2.4.1. Overall System Design 10 2.4.2. Master Unit Design 11 2.4.2.1. Master Unit Hardware Design 11 2.4.2.2. Master Unit Software Design 13 2.4.3. Slave Unit Design – User Interface 14 2.4.3.1. Slave Unit Hardware Design 14 2.4.3.2. Slave Unit Software Design 17 3. Resource and Resource Schedules 20 3.1. Requirements 20 3.2. Schedule 25 4. Project Team Information 28 5. Closing Summary 29 6. References 29 Appendix A: Parking Enforcement Officer Evaluation Form 30 Appendix B: Patron Evaluation Form 31

i

List of Figures Figure 1 : System level block diagram 11 Figure 2 : Server unit hardware block diagram 12 Figure 3 : Slave unit hardware block diagram 14 Figure 4 : Software flowchart for patron functions 18 Figure 5 : Software flowchart for administrator functions 19 Figure 6 : Gantt Chart – Project tasks and subtasks 26 Figure 7 : Gantt Chart – Project deliverables 27

ii

List of Tables Table 1 : Personnel effort requirements (original) 21 Table 2 : Personnel effort requirements (revised) 21 Table 3 : Other resource requirements (original) 22 Table 4 : Other resource requirements (revised) 22 Table 5 : Financial requirements (original) 23 Table 6 : Financial requirements (revised) 24

iii

List of Symbols and Definitions A Assembly language

A low-level computer language that consists of mnemonic codes and symbolic addresses corresponding to machine-language instructions

B C C A high-level object-oriented programming language C# An object-oriented programming language based on the design principles of Java D – E – F – G – H J Java

A high-level object-oriented programming language that allows small application programs to be downloaded from a server to a client along with the data that each program processes (developed by Sun Microsystems)

K L LCD

Liquid crystal display, a low-power digital display that uses liquid crystal cells that change reflectivity in an applied electronic field

M Motherboard

For this project, it is a main circuit board of the embedded computer through which all signals are directed. MySQL MySQL is a fast-relational database manager. A database manager enables adding, retrieving, and processing information stored in a database. The relational aspect of MySQL means that data is stored in separate tables rather than one large table. Relations between each table can be established and information can be retrieved using structured query language (SQL).

N – O – P – Q R RAM

Random-access memory, the primary working memory in a computer used for the temporary storage of programs and data and in which the data can be accessed directly and modified

iv

S SQL A standardized language that approximates the structure of natural English for obtaining information from databases

T U USB

Universal serial bus, a plug-and-play interface between a computer and peripheral devices, such as printers, modems, and keyboards

V Visual Basic A programming language and environment developed by Microsoft based on the

BASIC language using graphical programming environment and a paint metaphor for developing user interfaces.

W Wired Ethernet

A trademark for a system for exchanging messages between computers on a local area network using wired coaxial, fiber optic, or twisted-pair cables

X – Y – Z

v

1. Introductory Materials This section will define the problem, operating environment, intended users and uses, assumptions and limitations, and expected end product of the project. 1.1 Abstract There are multiple pay-for-parking lots on the Iowa State campus managed by the Department of Public Safety (DPS). Currently, two of these lots are controlled by multi-space parking meter systems located near the lots. Several undesirable aspects of these units have left DPS searching for a better solution. This project will provide a solution by developing a multi-space meter system that provides the same functionalities as the current units, as well as adding new functions. The developed system will be more cost-effective, will be easier to use for people parking in the lots, and will make management of the lots more straightforward and more effective for DPS. This will make for a better experience for those using the system and will allow DPS to focus resources on other

ore pressing issues. m 1.2 Acknowledgement The team would like to acknowledge the following people for their contributions, both financially and intellectually, to the project: Doug Houghton, Captain, Department of Public Safety, Iowa State University. We would also like to thank the course instructor and project advisors, Dr. John W. Lamont and Professor Ralph Patterson III, for their guidance and advice regarding the project. 1.3 Problem Statement The following sections will provide a general overview of the problem that this project seeks to address, as well as the proposed method of solving it. 1.3.1 General Problem Statement At Iowa State University, as at other colleges around the United States, many issues arise concerning the availability of parking on or near campus. This has led to the development of several pay-for-parking lots on the Iowa State campus. Currently, use of these lots is controlled through centralized units that are able to monitor multiple spaces at once. This provides some advantages over traditional parking meters from an administrative standpoint, e.g. money can be collected at once from a central location. However, while the current system currently has some benefits, there is still much left to be desired. The fact that the units cannot communicate with one another means that if a space is paid for on one machine, time can only be added later to that same exact machine. Also, when the lot is checked for offenders, each machine must be queried

1

individually, which increases the time to check the lot. Lastly, this has implications for robustness. If one unit is disabled, all the data stored there is lost. Another undesirable aspect of the current system is that the units are very hard to program. DPS would like to be able to set the hourly rates of the lots, as well as program in university holidays. In the current system, doing so requires a specialist. This process is both expensive and time consuming. The project will be achieved by utilizing the efforts of two teams, May 04-02 and Dec 04-02. May 04-02 will be responsible for the slave units, while Dec 04-02 will be responsible for the master unit. 1.3.2 General Solution Approach The solution proposed by this project is to provide a system to monitor the pay-for-parking lots that will have all the benefits of the current system as well as to improve on its negative aspects. The system will be more user-friendly, more cost-effective, more durable, and easier to maintain. In this solution, control of the parking lots will be implemented with several, multi-space, communicating units. Because the units will be able to communicate, users of the lot may add time via any machine. Also, DPS will only have to query one machine to receive a complete list of lot activity. Lastly, this feature, combined with a redundant central processor and memory, will greatly increase the robustness of the system. The new units will also have easier to use interfaces. This will allow DPS the ability to easily program in rate changes and holidays. This will also make it easier for people parking in the lots to utilize the system. Lastly, the unit will be implemented with standard off the shelf computer hardware. This will decrease the cost to the University, both in initial cost and in maintenance cost. 1.4 Operating Environment The designed units will be located outdoors, and thus must operate in a large range of temperatures as well as withstand the rain, snow, and other weather conditions present in Ames, Iowa. The system will be used on a regular basis, and thus must be designed to withstand extended use. Lastly, the units will be located on a college campus, and thus must be resistant to attempts at vandalism. 1.5 Intended Users and Uses The users of this system fall into two main groups, users of the lots, and administrators of the lots.

2

1.5.1 Users The first group is made up of the people that park in the lots. This group includes (but is not limited to):

• College students attending Iowa State University • Faculty and staff employed by Iowa State University • Visitors to the Iowa State campus

The first and second groups include those that monitor the parking lots, i.e. the Iowa State University Department of Public Safety employees. 1.5.2 Uses The system will have two main categories of uses, separated by the two groups of users (see above). For the people who park in the lots, the system will:

• Allow parking spaces to be paid for, either by first selecting an amount of time, or by simply putting money in.

• Allow time to be added to any parking space from any unit in that lot. • Provide a hard-copy receipt to the user if desired.

For the Department of Public Safety, the system will:

• Allow DPS to monitor and enforce the paid usage of the parking lots. • Allow DPS to gather parking lot usage statistics. • Allow DPS to change hourly rates and set holidays.

1.6 Assumptions and Limitations The information provided below shall serve to define the assumptions and limitations inherent in the design of the device resulting from this project.\ 1.6.1 Assumptions

• The lot size will be equal to or less than 1000 spaces. • No change will be returned to users. • Power will be provided to the units, except during extended power outages. • The units will accept only nickels, dimes, and quarters as payment.

3

1.6.1 Limitations

• The time available to complete the project is limited. • The unit must be weatherproof and theft-proof. • The units must be within 100 meters of Ethernet hub. • The main processing unit must consist of two redundant processors. • The main processing unit must have redundant storage. • The user interface will be compact and user-friendly. • Backup batteries must be able to allow the machine to run for four hours in the

event AC electricity is unavailable. • The system must provide all of the capabilities of the current system. • DPS must be able to change rates and holidays without outside assistance. • The units must allow users to add time to their current amount of time. • The system must provide information on current stall payment status (paid or

unpaid) for DPS enforcement. • The system must accommodate time of day and holiday rates. • The unit must have a receipt printer which will print receipts upon request.

1.7 Expected End Product and Other Deliverables The end products of this project will be a prototype multi-space parking meter system, a user manual, and a technical specification. These deliverables are described below:

• Multi-space parking meter system

The system will consist of a set of units configured to communicate with each other and able accommodate a lot size of up to 1000 parking spaces. The master unit will store all of the lot information, and the slave unit(s) will offer the same user interface but will use data from the master unit. The system will allow patrons of the lot to pay for parking, and allow DPS to monitor the usage and enforcement of the lot.

• User Manual

The user manual will be a document describing the operation of the machines, in a non-technical manner that can be understood by any user of the system. These operations described in the manual include monitoring occupancy, making rate changes, and enforcement functions. A preliminary manual will be delivered when the system becomes ready for testing, and a final draft will be delivered in December of 2004.

4

• 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. This document not designed for common users, but instead as a resource for future designers of this system. The technical specification of the system will be delivered in December of 2004.

• Project Plan The project plan is a document that defines the project and the planning for the completion of the project. It describes how design decisions were made for the project and defines the overall problem domain. The project plan will be delivered in February of 2004.

• 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. The design report will be delivered in May of 2004.

• 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 through to the testing and finally the end product description. This document will also provide suggestions for future work on the project. The final report will be delivered in December of 2004.

5

2. Approach and Product Design Results This section provides the details of the approach and design that describe the process of developing the end product. 2.1 Proposed Approach This section shall explain the planned method of completing the project. 2.1.1 Design Objectives Develop a multi-space parking meter system with the following objectives:

• Added features The system will provide the features of the current system and will expand upon them with additional features desired by DPS. These features include a statistical database system, a user friendly interface, redundant processor and memory backup, and multiple levels of administration for accessing and modifying the system.

• Reduced cost

The project will produce a system that is significantly more cost effective than the current machines and other commercially available systems.

• Easier reprogramming

The system will be easy for DPS to make rate and system changes.

• Redundant system

The system will have a redundant processor and database system that will provide extra stability.

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

• Accepts client input/output

The system will connect to a remote computer using an Ethernet connection. The system will allow DPS to change hourly rates, time of day rates, holiday rates, or modify any code that is installed on the master unit.

6

• Manages parking space availability

The system will keep track of which parking spaces are currently paid for and ending time.

• Communication functionality

The system will allow for communication between interfaces using Ethernet connection.

• Statistical Reporting

The system will allow for statistical reporting to DPS. This statistical system will keep track of space usage, coin collection times, and other requested statistics.

2.1.3 Design Constraints The project shall run with in the following constraints.

• Weather resistance

The system must be able to withstand all weather conditions an outdoor system may experience on the Iowa State University campus. These include extremes of temperature and precipitation as well as severe winds and associated debris.

• Durability

The system must be durable, long lasting, and secure. The unit must be able to withstand theft, vandalism, corrosion, and minor collisions with vehicles.

• Power requirements

The master/slave system must be run off standard 110 AC power as well as a battery backup.

• Hardware redundancy requirements

The master system must use a board with redundant processing and storing capabilities to decrease chances of failure.

7

• Connectivity requirements

The master/slave system must be able to complete all necessary communications over a standardized Ethernet interface.

• Machine size requirements

The control hardware will be placed inside one of the slave units, so it must be of a size that facilitates installation, maintenance, and use. The size of the machine must also be sufficiently large so as to allow for the inclusion of all necessary internal components.

2.1.4 Technical Approach Considerations and Results The following hardware technologies shall be considered in the implementation of the end product.

• Master system hardware using dual processor-based system

A system of this type utilizing two separate processors would allow for backing up a processor if one were to fail. It has redundant capability to store data to two sets of memory. If one processor were to fail, the second processor would takeover automatically where the other quit. This helps alleviate downtime so the master control unit can process parking locations and continue to accept money.

The following software technologies shall be considered in the implementation of the end product.

• Assembly

The use of assembly would allow for precise control over memory usage and data handling. It would make for an arduous development process, however.

• MySQL

The use of MySQL would allow for easy creation of the central database and integration with the Windows XP operating system.

• C/C# The use of C/C# would allow for the creation of a modular, robust, and easily modifiable software product. C/C# may be used for creation of a user interface application located on the master device as well as in the creation of the redundant failover process.

8

• Visual Basic.Net The use of Visual Basic.Net would allow for easy graphical user interface.

Selection: MySQL will be used as the database server software as it allows for easy creation of a central database and is compatible with the Windows XP operating system. Applications utilizing the C computer language may also be used in two areas: communication between master/slave devices and for implementing the redundant failover system.

2.2 Testing Approach Considerations Testing is an important part of every design process to ensure that the end product meets the needs for which it was designed. The following section will detail how the system hardware, software, and prototype will be tested. 2.2.1 Hardware Testing The system hardware needs to be tested to ensure that it can withstand extended use in the operating conditions of the system. All hardware elements have been tested by their manufacturers over a large range of temperatures, sufficient to endure the weather conditions in Ames, Iowa. Thus, no further temperature testing is necessary. Also, several hardware elements, such as the printer and coin acceptor are already in use by DPS, and have demonstrated their ability to withstand extended use. For these reasons, no separate hardware testing will be conducted in addition to testing the prototype. 2.2.2 Software Testing The software of the system must be tested to ensure that it is robust enough to withstand all possible user inputs, as well as unexpected events, such as a server crash or a power outage. The software will be tested in the following conditions.

• Full range of user inputs

All possible inputs for every function will be tested in the software. The results of the input will be checked to verify that the code operates correctly.

• Server crash

A server crash will be simulated to ensure that the software supporting the backup servers functions properly. After the simulated server crash, the contents of the database will be queried to make sure that the system continued functioning during and after the server crashed.

9

• Power outage

The software will be tested for a power outage by removing power to the system. The results will be closely observed to ensure that the system reboots correctly, and that important data is not lost.

2.2.3 System Prototype Testing The prototype of the system must be tested not only to verify correctness, but also to validate its ability to function when used by patrons and DPS employees. The system prototype will be placed in an actual parking lot, and will be used over a period of a few months. During this period, a sampling of DPS employees and parking patrons will be asked to fill out response forms. A sample of these forms can be found in Appendices A and B. Also, any problems encountered with the system prototype will be recorded and fixed in future iterations. 2.3 Recommendations for Project Continuation or Modification Considering the research and design work done this semester, the conclusion has been reached that this project should continue as originally planned. Additional work may be done during the summer to complete most of the testing stage and implement additional features. 2.4 Detailed Design The Following section details the design of the multi-space parking meter that will result from this project. 2.4.1 Overall System Design The multi-space parking meter to be produced during this project will consist of two distinct parts: the slave units and the master unit. The units will communicate with each other via an ethernet switch. The switch will allow for several slave units to communicate with the master unit. The master unit will consist of two systems for redundancy. Both the master and slave units will be further discussed in the sections to follow. Figure 1 on the next page shows an overview of the connectivity between the master and slave units.

10

Figure 1 – System level block diagram

2.4.2 Master Unit Design The following section details the hardware and software design of the master unit. 2.4.2.1 Master Unit Hardware Design The master unit portion of the parking meter system consists of redundant systems to maintain uptime in the event that primary master fails. If this event does occur the secondary master will take over until the primary master is online. Figure 2 illustrates a block diagram of the hardware design of the redundant master unit shown on the next page.

11

Figure 2 – Server unit hardware block diagram

The list below shows the specifications of the server unit. Computer (2 required)

SolarPC SB150 • Via Epia 5K motherboard

o RJ-45 Network Jack o Via C3 533 Processor

• 100W power supply Source: http://solarpc.com Cost: $209.98 ea.

Ram (2 required)

256MB Ram • PC133 • 168 pin dimm

Source: http://www.crucial.com Cost: $76.99

12

Network Switch SMC EZ6508TX

• 8 Port • 10/100 Mbs connectivity Source: http://www.newegg.com Cost: $34.00

Network Cables (4 required) Generic

• Cat5e • 100 Mbs bandwidth • 7 feet long Source: http://newegg.com Cost: $1.00 ea.

Solid State Memory (2 required) Disk on Chip

• 512 MB • IDE interface Source: Cost: $186.00

2.4.2.2 Master Unit Software Design The master unit portion of the parking meter system consists of redundant systems to maintain uptime in the event that primary master fails. If this event does occur the secondary master will take over until the primary master is online. The software that will be providing communication and database functionality is freeware and works across multiple platforms. C/C# will be used to create the necessary code to maintain a redundant system. Windows XP Embedded

Source: Iowa State University License Cost: free

MySQL

Source: http://www.mysql.com Cost: freeware

Apache Web server

Source: http://www.apache.org Cost: freeware

13

C/C#

Source: Iowa State University License Cost: free

2.4.3 Slave Unit Design – User Interface The following section details the hardware and software design of the slave unit for the multi-space parking meter system. Implementation of this part was done by another design team to be completed May 2004. The December 2004 team will complete any added functionality of this system. 2.4.3.1 Slave Unit Hardware Design The slave unit portion of the marking meter system consists of a low power personal computer connected to the peripheral devices necessary for operation of the parking meter’s user interface. Figure 3 below illustrates a block diagram of the hardware design of the user interface.

Figure 3 – Slave unit hardware block diagram

14

The specifications of the Slave unit portion of the system are as follows: Motherboard Via Epia 800 MHz motherboard

• Via C3 800MHz Processor • USB Ports • 1 EPP/ECP Parallel Port • 1 16C550 Serial Port • PS/2 Ports

Source: http://www.mini-box.com Cost: $150.00 RAM Crucial RAM

• 512 MB PC133 Source: http://www.crucial.com Cost: $80.00 LCD Display CrystalfontzCFA634

• 4x20 Character LCD • USB Interface • LED Backlight

Source: http://www.crystalfontz.com Cost: $75.00 Keypad StacoSwitch M151XX05

• 16-key • Rugged duty molded elastomer

Source: http://www.stacoswitch.com Cost: $90.00 Keypad Processor Motorola 6805

• Interface keypad to PS/2 port Source: Already procured (salvaged from old keyboard) Cost: $0

15

Coin Acceptor Coinco Global 700

• MDB interface • Accepts nickels, dimes, and quarters

Source: Iowa State DPS Cost: $0 Coin Acceptor Controller Upstate Networks Incorporated MDB2PC

• Serial interface to MDB protocol device Source: http://www.upstatenetworks.com/mdb/ Cost: $300.00 Printer Infinite Peripherals IPF-XTR-80S

• 80mm paper width • 8dot/mm resolution • Serial RS232 interface

Source: http://www.ipcprint.com Cost: $363.00 Printer Power Supply Infinite Peripherals SPU-230-24IP

• AC power in 24VDC power out Source: http://www.ipcprint.com Cost: $69.00 Solid State Memory M-Systems MDI1151-D512 512MBflash module

• Solid state memory with IDE interface Source: http://www.tri-m.com Cost: $100.00 Battery Backup (UPS) APC BK650MC

• 650VA/400W Source: http://www.newegg.com Price: $100.00

16

17

ATX Power Supply Enermax EG301P Source: Already procured (salvaged from computer) Cost: $0 2.4.3.2 Slave Unit Software Design Software flowcharts have been designed by the May-04 team to demonstrate how the user interface software will function. These flowcharts show the various system states and transitions between states. Figure 4 on the following page shows the software flowchart for patron functions. These functions are initiated when the patron enters a valid stall number. Figure 5, illustrates the software flowchart for administrator functions. These functions are accessed when an administrator enters one of the special administrative codes at the main screen. Some details have been omitted from this diagram to maintain clarity. For example, if a length of 15 seconds of inactivity is detected at any time while an administrator is logged in, the system will automatically log out of the administrator menu and return to the main menu.

Figure 4 - Software flowchart for patron functions

18

Figure 5 - Software flowchart for administrator functions

19

3. Resource and Resource Schedules This section is made up of two parts. The first defines all of the resource requirements of the system. The second part describes the projected schedule of the project in two Gantt charts. 3.1 Resource Requirements This section describes both the original and current estimates of resource requirements for personal, financial, and other resources. Table 1 and Table 2 on the next page show the personnel effort of individual team members for each of the following tasks:

• Task 1 — Project definition • Task 2 — Research and technology • Task 3 — Design • Task 4 — Implementation • Task 5 — Testing/verification • Task 6 — Demonstration • Overhead — Weekly meetings, discussions, travel time, and other misc. items

20

Table 1: Personnel Effort Requirements (Original)

Hours Personnel Name Task

1 Task

2 Task

3 Task

4 Task

5 Task

6 Overhead TOTAL

Joe Reinsma

11 12 36 76 16 13 45 209

Mikel Bezdek

10 10 31 76 17 12 44 205

John Goldbach

12 10 34 78 16 12 44 206

Andrew Ross

12 10 30 74 16 12 40 199

Irsan Halim

10 10 29 77 15 12 45 201

TOTAL 55 52 160 387 82 61 223 1020

Table 2: Personnel Effort Requirements (Revised)

Hours Personnel Name Task

1 Task

2 Task

3 Task

4 Task

5 Task

6 Overhead TOTAL

Joe Reinsma

10 18 28 77 14 8 48 203

Mikel Bezdek

9 8 20 78 15 7 46 183

John Goldbach

11 10 20 77 14 7 45 184

Andrew Ross

11 8 23 74 10 7 44 177

Irsan Halim

9 8 19 78 14 7 45 180

TOTAL 50 52 110 384 67 36 228 927 The revised estimates are based on a better understanding of the time requirements of the project and the tasks. The total personnel effort estimates change marginally. For the tasks that have been completed (Task 1, Task 2, and Task 3), the actual effort hours are recorded. For the remaining tasks, updated estimates have been made.

21

Table 3, Table 4, Table 5, and Table 6 summarize both the original and current estimated financial cost of equipments and other resource requirements to design a working prototype.

Table 3 : Other Resource Requirements (Original)

Item Team Hours Cost Motherboard/Processor1 0 $150 RAM1 0 $50 Storage1 0 $200 Motherboard/Processor2 0 $150 RAM2 0 $50 Storage2 0 $200 LCD 0 $75 Keypad 0 $100 Misc. Buttons 0 $50 Printer Controller 0 $120 Ethernet Switch 0 $57 UPS Battery Backup Unit 0 $100 Housing 0 $100 Project Poster 10 $50

TOTAL 10 $1452

Table 4 : Other Resource Requirements (Revised)

Item Team Hours Cost Motherboard/Processor1 0 $189.99 RAM1 0 $76.99 Storage1 0 $186 Power Supply1 0 $19.99 Motherboard/Processor2 0 $189.99 RAM2 0 $76.99 Storage2 0 $186 Power Supply2 0 $19.99 Ethernet Switch 0 $38 Project Poster 14 $54.49

TOTAL 14 $1038.43 There are quite some changes to the hardware requirements from the original other resource requirements in Table 3 to the revised one in Table 4. The hardware parts like LCD, keypad, buttons, printer controller, and battery backup unit are not included in the revised other resource requirements because these parts are taken care by the other group (May04-02). There is also some adjustment for the prices of the parts after more research have been done to get the best available hardware in the market.

22

Table 5 : Financial Requirements (Original)

Item Cost Parts and materials

Motherboard/Processor1

RAM1

Storage1

Motherboard/Processor2

RAM2

Storage2

LCD Keypad Misc. Buttons Printer Interface Ethernet Switch UPS Battery Backup Unit Housing Project Poster

$150 $50 $200 $150 $50 $200 $75 $100 $50 $120 $57 $100 $100 $50

Services Shipping and handling Binding

$50 $30

TOTAL (w/o Labor) $1532

Labor ($10.50 / hour) Joe Reinsma Mike Bezdek John Goldbach Andrew Ross Irsan Halim

$2331 $2100 $2163 $2037 $2079

TOTAL (w/ Labor) $12062

23

Table 6 : Financial Requirements (Revised)

Item Cost Parts and materials

Motherboard/Processor1

RAM1

Storage1

Power Supply1

Motherboard/Processor2

RAM2

Storage2

Power Supply2

Ethernet Switch Project Poster

$189.99 $76.99 $186

$19.99 $189.99 $76.99 $186

$19.99 $38

$54.49 Services

Shipping and handling Binding

$20 $30

TOTAL (w/o Labor) $1088.43

Labor ($10.50 / hour) Joe Reinsma Mike Bezdek John Goldbach Andrew Ross Irsan Halim

$2131.5 $1921.5 $1932

$1858.5 $1890

TOTAL (w/ Labor) $10791.93

24

25

3.2 Schedules The following section includes two Gantt charts detailing the projected schedule of tasks. The illustrated calendars will span the full length of the project, which is two semester long. The first Gantt chart (Figure 5) contains the original and revised schedules for the project tasks. The second Gantt chart (Figure 6) displays the original and revised schedules of class deliverables. The timelines for the various tasks are based on the team’s best estimates of time requirements, as well as the Senior Design class and deliverable schedules. The team will adhere to the schedule to the best of its ability in order to keep the project on task. The team is also planning to do most of the software implementation during the summer as some of the team members will be available to work on the project during this period. In consequence, we will have most of the implementation and possible testing tasks done during the summer.

Project Schedule

Figure 6 – Project tasks and subtasks

26

27

Figure 7 – Project deliverables

4. Project Team Information The following individuals are those directly involved in the definition, development, and implementation of this project. 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 324 Town Engineering Iowa State University Ames, IA 50010 Vox: 515-294-3600 Fax: 515-294-6760 jwlamont@iastate.edu

Professor Ralph Patterson III 326 Town Engineering Iowa State University Ames, IA 50010 Vox: 515-294-2428 Fax: 515-294-6790 repiii@iastate.edu

Team Members:

Joe Reinsma – CprE 528 Welch Ave #10 Ames, IA 50014 952-239-2449 jreinsma@iastate.edu

John Goldbach - CprE 225 N. Hyland Ames, IA 50014 952-237-8565 jgold@iastate.edu

Mikel Bezdek - CprE 1331 Frederickson Court Ames, IA 50010 515-572-7640 mbezdek@iastate.edu

Andrew Ross – EE 124 N. Franklin Ames, IA 50014 319-350-9496 ajross@iastate.edu

Irsan Halim – CprE 632 Squaw Creek #3 Ames, IA 50010 515-441-0389 ihalim@iastate.edu

28

5. Closing Summary The need for a powerful and easy to use, yet cost effective solution for managing vehicle parking on the campus of Iowa State University has never been greater. Solutions currently available are not feature rich enough, too difficult for easy use, or are too expensive. It is for these reasons that the University is commissioning the creation of the multiple space parking meter system described in this document. The system resulting from the work of this project team will exceed the University’s current needs and will allow for easy modification in order that it may continue to meet the University’s needs for years to come. This will result in increased revenues for the University, and will allow those managing parking to focus on other duties. 6. References Prototype Parking Metering System May 04-02 10 February 2004 from http://sd.theotron5000.com/files/designdocument.pdf

29

Appendix A Parking Enforcement Officer Evaluation Form

Tester Name:___________________________ Date Completed:_________________ Tester Phone #:__________________ Tester Email Address:___________________ Instructions: The purpose of this test is to evaluate the use of this system to monitor and enforce parking lot payments. Before completing the survey below, complete the following tasks: 1) Print the list of paid and unpaid stalls for enforcement. 2) Empty the coin box and retrieve the auditing receipt. 3) Print the diagnostics report. Please circle the number that best describes your response as follows: 1 – Very Poor 2 – Poor 3 – Indifferent 4 – Good 5 – Excellent Were the instructions clear and easy to understand? 1 2 3 4 5 Was it clear and easy how to print the enforcement receipt? 1 2 3 4 5

Did the enforcement receipt have all of the information that you needed? If not, please comment on what info was missing. 1 2 3 4 5

Did the auditing receipt print when you opened the unit to empty the coin box? 1 2 3 4 5

Did the auditing receipt that printed when you opened the coin box have the information that you desired? If not, please comment on what info was missing.

1 2 3 4 5

Were you easily able to print a diagnostic report? 1 2 3 4 5

Did the diagnostic report contain all of the information that you thought was needed?

1 2 3 4 5

Were the key inputs easy to use? 1 2 3 4 5

Did the instructions clearly indicate which keys you were to press? 1 2 3 4 5

What is your overall impression of this machine 1 2 3 4 5

Please provide any additional comments or suggestions on the back of this form:

30

Appendix B Patron Evaluation Form

Tester Name:___________________________ Date Completed:_________________ Tester Phone #:__________________ Tester Email Address:___________________ Instructions: The purpose of this test is to evaluate the use of the parking meter. Before completing the survey below, please complete the following tasks: 1) Pay for a parking space by entering coins first and not by choosing the amount of time you would like to pay for. 2) Add time to the parking space by entering the time you would like to pay for and then depositing coins. 3) Complete the above transactions with and without printing a receipt. 5) Attempt to cancel the sale before you insert coins. Please circle the number that best describes your response as follows: 1 – Very Poor 2 – Poor 3 – Indifferent 4 – Good 5 – Excellent Were the instructions clear and easy to understand? 1 2 3 4 5 Was it clear and easy how to enter the stall number? 1 2 3 4 5

Was it clear and easy to enter the coins first and not choose the amount of time for payment? 1 2 3 4 5

Was it clear and easy to choose the amount of time to pay for and then insert coins? 1 2 3 4 5

Was it clear and easy to print a receipt? 1 2 3 4 5 Did the receipt have all of the information that you thought was necessary? If not, please comment on what was missing. 1 2 3 4 5

Were you able to cancel the transaction before depositing coins? 1 2 3 4 5

Were the key inputs easy to use? 1 2 3 4 5

Did the instructions clearly indicate which keys you were to press? 1 2 3 4 5

What is your overall impression of this machine 1 2 3 4 5

Please provide any additional comments or suggestions on the back of this form:

31