Prototype Parking Metering System Phase 2

Transcription

1 Prototype Parking Metering System Phase 2 Design Report DEC 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

2 Table of Contents List of Figures ii List of Tables iii List of Symbols and Definitions iv 1. Introductory Materials Abstract Acknowledgement Problem Statement General Problem Statement General Solution Approach Operating Environment Intended Users and Uses Users Uses Assumptions and Limitations Assumptions Limitations Expected End Product and Other Deliverables 4 2. Approach and Product Design Results Proposed Approach Design Objectives Functional Requirements Design Constraints Technical Approach Considerations and Results Testing Approach Considerations Hardware Testing Software Testing System Prototype Testing Recommendations for Project Continuation or Modification Detailed Design Overall System Design Master Unit Design Master Unit Hardware Design Master Unit Software Design Slave Unit Design User Interface Slave Unit Hardware Design Slave Unit Software Design Resource and Resource Schedules Requirements Schedule Project Team Information Closing Summary References 29 Appendix A: Parking Enforcement Officer Evaluation Form 30 Appendix B: Patron Evaluation Form 31 i

3 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

4 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

5 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 M LCD Liquid crystal display, a low-power digital display that uses liquid crystal cells that change reflectivity in an applied electronic field 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

6 S SQL A standardized language that approximates the structure of natural English for obtaining information from databases T U V W USB Universal serial bus, a plug-and-play interface between a computer and peripheral devices, such as printers, modems, and keyboards 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. 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

7 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 multispace 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 costeffective, 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 more pressing issues. 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 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

8 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 and Dec May will be responsible for the slave units, while Dec will be responsible for the master unit General Solution Approach The solution proposed by this project is to provide a system to monitor the pay-forparking 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

9 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 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.\ 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

10 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 User Manual 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. 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

11 Technical Specification Project Plan Design Report Final Report 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 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 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 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

12 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 Design Objectives Develop a multi-space parking meter system with the following objectives: Added features Reduced cost 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. The project will produce a system that is significantly more cost effective than the current machines and other commercially available systems. Easier reprogramming Redundant system The system will be easy for DPS to make rate and system changes. The system will have a redundant processor and database system that will provide extra stability 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

13 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 Design Constraints The project shall run with in the following constraints. Weather resistance Durability 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. 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

14 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 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 MySQL C/C# The use of assembly would allow for precise control over memory usage and data handling. It would make for an arduous development process, however. The use of MySQL would allow for easy creation of the central database and integration with the Windows XP operating system. 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

15 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 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 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 Server crash 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. 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

16 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 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 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

17 2.4.2 Master Unit Design Figure 1 System level block diagram The following section details the hardware and software design of the master unit 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

18 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: Cost: $ ea. Ram (2 required) 256MB Ram PC pin dimm Source: Cost: $

19 Network Switch SMC EZ6508TX 8 Port 10/100 Mbs connectivity Source: Cost: $34.00 Network Cables (4 required) Generic Cat5e 100 Mbs bandwidth 7 feet long Source: Cost: $1.00 ea. Solid State Memory (2 required) Disk on Chip 512 MB IDE interface Source: Cost: $ 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: Cost: Iowa State University License free MySQL Source: Cost: freeware Apache Web server Source: Cost: freeware 13

20 C/C# Source: Cost: Iowa State University License free 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 The December 2004 team will complete any added functionality of this system 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

21 The specifications of the Slave unit portion of the system are as follows: Motherboard RAM Via Epia 800 MHz motherboard Via C3 800MHz Processor USB Ports 1 EPP/ECP Parallel Port 1 16C550 Serial Port PS/2 Ports Source: Cost: $ LCD Display Keypad Crucial RAM 512 MB PC133 Source: Cost: $80.00 CrystalfontzCFA634 4x20 Character LCD USB Interface LED Backlight Source: Cost: $75.00 StacoSwitch M151XX05 16-key Rugged duty molded elastomer Source: Cost: $90.00 Keypad Processor Motorola 6805 Interface keypad to PS/2 port Source: Already procured (salvaged from old keyboard) Cost: $0 15

22 Coin Acceptor Coinco Global 700 MDB interface Accepts nickels, dimes, and quarters Source: Iowa State DPS Cost: $0 Coin Acceptor Controller Printer Upstate Networks Incorporated MDB2PC Serial interface to MDB protocol device Source: Cost: $ Infinite Peripherals IPF-XTR-80S 80mm paper width 8dot/mm resolution Serial RS232 interface Source: Cost: $ Printer Power Supply Infinite Peripherals SPU IP AC power in 24VDC power out Source: Cost: $69.00 Solid State Memory M-Systems MDI1151-D MBflash module Solid state memory with IDE interface Source: Cost: $ Battery Backup (UPS) APC BK650MC 650VA/400W Source: Price: $

23 ATX Power Supply Enermax EG301P Source: Already procured (salvaged from computer) Cost: $ 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. 17

24 Figure 4 - Software flowchart for patron functions 18

25 Figure 5 - Software flowchart for administrator functions 19

26 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

27 Table 1: Personnel Effort Requirements (Original) Hours Personnel Task Task Task Task Task Task Name Overhead TOTAL Joe Reinsma Mikel Bezdek John Goldbach Andrew Ross Irsan Halim TOTAL Table 2: Personnel Effort Requirements (Revised) Hours Personnel Task Task Task Task Task Task Name Overhead TOTAL Joe Reinsma Mikel Bezdek John Goldbach Andrew Ross Irsan Halim TOTAL 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

28 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/Processor 1 0 $150 RAM 1 0 $50 Storage 1 0 $200 Motherboard/Processor 2 0 $150 RAM 2 0 $50 Storage 2 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/Processor 1 0 $ RAM 1 0 $76.99 Storage 1 0 $186 Power Supply 1 0 $19.99 Motherboard/Processor 2 0 $ RAM 2 0 $76.99 Storage 2 0 $186 Power Supply 2 0 $19.99 Ethernet Switch 0 $38 Project Poster 14 $54.49 TOTAL 14 $ 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

29 Table 5 : Financial Requirements (Original) Item Cost Parts and materials Motherboard/Processor 1 $150 RAM 1 $50 Storage 1 $200 Motherboard/Processor 2 $150 RAM 2 $50 Storage 2 $200 LCD $75 Keypad $100 Misc. Buttons $50 Printer Interface $120 Ethernet Switch $57 UPS Battery Backup Unit $100 Housing $100 Project Poster $50 Services Shipping and handling $50 Binding $30 TOTAL (w/o Labor) $1532 Labor ($10.50 / hour) Joe Reinsma $2331 Mike Bezdek $2100 John Goldbach $2163 Andrew Ross $2037 Irsan Halim $2079 TOTAL (w/ Labor) $

30 Item Parts and materials Motherboard/Processor 1 RAM 1 Storage 1 Power Supply 1 Motherboard/Processor 2 RAM 2 Storage 2 Power Supply 2 Ethernet Switch Project Poster Table 6 : Financial Requirements (Revised) Cost $ $76.99 $186 $19.99 $ $76.99 $186 $19.99 $38 $54.49 Services Shipping and handling $20 Binding $30 TOTAL (w/o Labor) $ Labor ($10.50 / hour) Joe Reinsma $ Mike Bezdek $ John Goldbach $1932 Andrew Ross $ Irsan Halim $1890 TOTAL (w/ Labor) $

31 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. 25

32 Project Schedule Figure 6 Project tasks and subtasks 26

33 Figure 7 Project deliverables 27

34 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 Vox: Fax: Faculty Advisors: Dr. John Lamont 324 Town Engineering Iowa State University Ames, IA Vox: Fax: Professor Ralph Patterson III 326 Town Engineering Iowa State University Ames, IA Vox: Fax: Team Members: Joe Reinsma CprE 528 Welch Ave #10 Ames, IA John Goldbach - CprE 225 N. Hyland Ames, IA jgold@iastate.edu Mikel Bezdek - CprE 1331 Frederickson Court Ames, IA mbezdek@iastate.edu Andrew Ross EE 124 N. Franklin Ames, IA ajross@iastate.edu Irsan Halim CprE 632 Squaw Creek #3 Ames, IA ihalim@iastate.edu 28

35 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 February 2004 from 29

36 Appendix A Parking Enforcement Officer Evaluation Form Tester Name: Date Completed: Tester Phone #: Tester 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? Was it clear and easy how to print the enforcement receipt? Did the enforcement receipt have all of the information that you needed? If not, please comment on what info was missing Did the auditing receipt print when you opened the unit to empty the coin box? 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. Were you easily able to print a diagnostic report? Did the diagnostic report contain all of the information that you thought was needed? Were the key inputs easy to use? Did the instructions clearly indicate which keys you were to press? What is your overall impression of this machine Please provide any additional comments or suggestions on the back of this form: 30

37 Appendix B Patron Evaluation Form Tester Name: Date Completed: Tester Phone #: Tester 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? Was it clear and easy how to enter the stall number? Was it clear and easy to enter the coins first and not choose the amount of time for payment? Was it clear and easy to choose the amount of time to pay for and then insert coins? Was it clear and easy to print a receipt? Did the receipt have all of the information that you thought was necessary? If not, please comment on what was missing Were you able to cancel the transaction before depositing coins? Were the key inputs easy to use? Did the instructions clearly indicate which keys you were to press? What is your overall impression of this machine Please provide any additional comments or suggestions on the back of this form: 31