Prototype Parking Meter Phase 4

Prototype Parking Meter – Phase 4

Final Report

Project team: Dec05-02

Client Iowa State University Parking Division

Advisors John W. Lamont, Ralph E. Patterson III

Team Members Brandon Crist, Seth Graber, Daniel Helvick Jeremy Meeks, Erik Sautter

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. December 14, 2005

ii Table of Contents

Item Page

Table of Contents i-ii List of Figures iii List of Tables iv List of Definitions v-vi Executive Summary 1 Acknowledgement 1 1. Problem Statement 1-2 1.1. General Problem Statement 1 1.2. General Solution Approach 2 2. Operating Environment 2 3. Intended Users 2-3 4. Intended Uses 3 5. Assumptions 3 6. Limitations 4 7. Expected End Result and Other Deliverables 4-5 7.1. Multi-space parking meter system and second slave unit 4 7.2. Complete parts list and assembly/setup instructions 4 7.3. Formal test plan and test cases 5 7.4. End-user documentation 5 8. Project Approach and Results 5-14 8.1 End-Product Functional Requirements 5 8.2 Design Requirements and Constraints 5 8.3 Approaches Considered and Used 7 8.4 Detailed Design 7 8.5 Implementation Process 11 8.6 End-Product Testing 12 8.6.1 Testing Methodology 12 8.6.2 Testing Results 13-14 8.7 Product End Results 14 9. Estimated Resources and Schedules 15-19 9.1 Estimated Resources 15-18 9.2 Schedules 18-19 10. Project Evaluation 19-21 11. Recommendations for Additional Work 21 12. Lessons Learned 21-23 13. Risk Management 23-25 13.1 Anticipated Risks 23 13.2 Anticipated Risks Encountered 23 13.3 Unanticipated Risks Encountered 24 13.4 Resultant Changes 24-25 14. Project Team Information 25-26

i Table of Contents (cont.)

Item Page

15. Closing Summary 26 16. References 26

ii List of Figures

Item Page

Figure 8.2-1 – Client Unit Hardware Block Diagram 8 Figure 8.4-2 – Flowchart for Customer Functions Software 11 Figure 8.4-3 – Flowchart for Administrator Functions Software 12 Figure 9.2-1 – Project Schedule 19 Figure 9.2-2 – Project Deliverables Schedule 19

iii List of Tables

Item Page

Table 9-1 – Original Personnel Effort Requirements 15 Table 9-2 – Updated Personnel Effort Requirements 15 Table 9-3 – Original Other Resource Requirements 16 Table 9-4 – Updated Other Resource Requirements 16 Table 9-5 – Original Financial Resource Requirements 17 Table 9-6 – Updated Financial Resource Requirements 18

iv 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 States.

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

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.

H-I-J-K-L

Linux: An open-source operating system.

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

v List of Definitions

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.

T-U-V-W

Windows XP Embedded: A small version of the Windows XP operating system tailored to embedded computer applications (such as the parking meter system described in this document).

X x86: The dominant processor architecture on the market today. Intel and AMD processors make use of x86 architecture.

vi Executive Summary ISU currently has two pay-for-parking lots that have computerized control units with receipt printout capability. The cost of each unit begins at $10,000 and rapidly increases to more than $75,000 as features are added. The project teams have been working with the ISU Parking Division to develop plans for a new, less expensive parking meter system. The objective of this project is to develop a demonstrable, microprocessor-based prototype parking meter unit with a number of features such as variable time-of-day rate, add-on time capability, etc. The May04-02, Dec04-02, and May05-02 project teams have developed a complete design and implemented a prototype unit. Working with the May05-02 and May06-02 teams, the Dec05-02 team has tested and debugged the prototype unit and will continue to provide support for it as well as adding features and fixing problems as requested. The project team also produced a detailed parts list and assembly/setup instructions so that additional parking meters systems may be constructed. The May06-02 team will construct a second unit and test it in conjunction with the current prototype.

Acknowledgement The Dec05-02 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 and May04-02, Dec04-02, May05-02, and May06-02 electrical / computer engineering senior design teams. We would also like to acknowledge our project advisors, Dr. John W. Lamont, and Professor Ralph Patterson III for their advice and guidance during the existence the project.

1. Problem Statement

The following sections will provide a general overview of the problem being addressed as well as the present solution for it.

1.1 General Problem Statement Availability of parking on or near campus has become a concern at Iowa State University. Several pay-for-parking lots have been installed on the Iowa State University campus because of this problem. Parking lots with traditional parking meters require one meter for every parking spot. The lots concerned with this project use centralized units that are able to accept money and track multiple spaces from one or two centralized locations in the lot. This setup provides advantages over the traditional parking meters, such as monitoring the entire lot and collecting money from centralized locations.

However, there are several problems with the current system. The current units lack the ability to communicate with one another. This means that when the lot is checked for offenders, each machine must be checked individually. Also, if a user wishes to add time to a space for which they have previously paid, they must return to the machine which they used previously. Finally, the lack of communication means that if one unit is disabled, all the data stored in it is lost.

1 Another problem is the current system 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 require that this be done by a specialist, a process that is both expensive and time consuming.

1.2 General Solution Approach This project will attempt to solve this problem by providing a 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, and in many ways improve on them. The new system will be more affordable and user-friendly, as well as easier to maintain. The solution in development will be implemented with multiple units all of which will communicate with a central server. All units will be able to communicate using a server/client solution, and users of the lot will be able to add time via any machine. The new system will allow DPS parking enforcement officers to receive a list of lot activity. In addition, the system will have a redundant central processor and memory, which will create a much more robust solution than is currently available. The new units will have a simple to use interface that will make it easier for people parking in the lots to use the system, and for DPS personnel to administer the system. Finally, the system will be implemented with standard computer hardware. This will make duplication easy and decrease the cost of construction and maintenance of the units. The May04-02 senior design team completed the first phase of the project. This group completed much of the initial design work. The second group, Dec04-02, completed the design and partly implemented a prototype unit. The current work will consist of two teams. The third group, May05-02, will complete the prototype implementation and produce a user’s guide for the system, as well as a detailed technical specification. The fourth phase will be completed by this team, Dec05-02, which will be responsible for testing the prototype unit and fixing problems found with it (with the support of the May05-02 team), as well as producing a parts list and assembly/setup instructions, and building a second client parking meter unit. The Dec05-02 team will also generate a list of the common tasks for each class of user for the system, as well as instructions on how to perform these tasks.

2. Operating Environment

The new system will be installed in the east side of the parking lot at the Armory building at Iowa State University in Ames, IA. It must be able to withstand all the weather conditions present in this location. It will be able to deal with both extremes of temperatures, as well as all forms of precipitation such as rain, snow, and hail. It will be used on a regular basis, and often by users that may treat the unit roughly. The units must be durable and designed to withstand extended abuse by its users because of these conditions. Finally, because the unit will be located on a college campus, it must be sturdy, and resistant to attempts at vandalism and theft.

3. Intended Users

Three classes of users will use the system. The first class includes college students at Iowa State University, faculty and staff of Iowa State University, and visitors to the Iowa

2 State University campus. These users will use the system exclusively to pay for parking time.

The second class of users is DPS parking enforcement officers (administrators). They will need additional functionality in order to monitor the parking lots.

The third class of user is the supervisor. This user will have access to all the features available to the administrator class of users, in addition to the ability to change settings of the system, such as the rates.

4. Intended Uses

The system will have three classes of users (see Section 3), each of which has access to different functions. The robustness of the system is too great to put a comprehensive list of all features, so below can be found a few examples of functions for each class of user.

• For the first class of users, people that park in the lot, the system will: o Allow customers to add time to a parking space by selecting amount of additional time, selecting an ending time, or adding money until the desired amount of time is reached o Allow time to be added to a parking space from any unit connected to the server unit o Print a hard-copy receipt if the user desires

• For the second class of users, administrators, the system will: o Allow users to monitor paid and unpaid parking spots in the lot o Allow users to gather parking lot statistics

• In addition to the features above, for the supervisor class of users the system will: o Allow users to change hourly rates o Allow users to set holidays o Allow users to add administrator or supervisor users

5. Assumptions

Below is a list of all the assumptions taken into account when designing the system:

• The lot size will be no more the 1000 spaces • The units will not provide change to customers • AC power will be provided to the unit • The units will only accept nickels, dimes, and quarters as payment • Iowa State University Facilities Department will install the system and any subsequent systems • Adequate finances will be available to build a second client unit

3 6. Limitations

The system has a few functional requirements that were taken into account when designing the system. Below is a list of a few of the limitations that were set by either the project team or DPS.

• 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 system must allow for different rates, depending on the time of day and holidays • The hardware unit must print a receipt upon request • The server unit must consist of two redundant processors • The server unit must have separate storage on each processor • The unit must be able to run for four hours or more if power goes out • Users should be able to add time to their current remaining amount • The hardware must provide the current payment status of the lot for parking enforcement • The parts list for the subsequent units must consist of parts which are low-cost, interchangeable, reliable, backwards-compatible with the current prototype, and readily available

7. Expected End Product and Other Deliverables

The end products for this project will be a fully functional server/client, multi-space parking meter system, a secondary client unit in production by the May06-02 team, a complete parts list and assembly/setup instructions for subsequent units, and a formal test plan and test cases designed to exhaustively test the prototype parking meter system. Also, documentation on the basic functions of the parking meter system will be made available to DPS so that their employees will be able to learn how to use the system.

7.1 Multi-space parking meter system This system will consist of one or more client computers connected to a central server computer. The system will be capable of handling up to 1000 parking spaces. The server unit will store all of the parking lot information. The client unit(s) will retrieve this information and act as the interface from which parking time is purchased and administrators and/or supervisors can update pay rates, change parking schedules and manage a parking lot. A secondary client unit will be built using the parts list and assembly/setup instructions described below, tested, and supplied to DPS by the Dec06- 02 and future senior design teams.

7.2 Complete parts list and assembly/setup instructions The parts list is a document containing a complete list of hardware parts needed to build either a client or a server parking meter unit. The assembly/setup instructions are in a

4 document detailing the steps required to assemble the hardware for a server or client unit and to correctly set up the software to administer a parking lot. This documentation is meant to build subsequent parking meters with interchangeable, cheap, easy-to-acquire parts. The team was also responsible for updating the software requirements specification where appropriate.

7.3 Formal test plan and test cases The formal test plan is a document specifying a formal procedure for testing the prototype parking meter unit. The test cases are a series of documents that describe, in detail, test procedures meant to exhaustively test the functionality of the prototype parking meter system. The test cases are written as functional (black-box) testing. As of the publication of this document (12/14/05), the formal test plan and test cases are complete.

7.4 End-user documentation The current team will provide a set of documentation instructing employees of DPS how to use the parking meter system. A list of common operations, and the instructions for performing those operations, will be generated for each of the three classes of users for the parking meter system.

8. Project Approach and Results

This section discusses the Dec05-02 team’s major project activities, including requirements, design, implementation, and testing.

8.1. End-Product Functional Requirements The key functional requirements the Dec05-02 team is concerned with are the requirements for the second client unit. The second client unit will perform identically in hardware software functionality and user (customer/administrator/supervisor) interfaces. It will therefore meet all functional requirements defined in the functional specification produced by the May05-02 team.

8.2. Design Requirements and Constraints The entire project was done under the following constraints and considerations.

 Weather Resistance The entire system must be able to withstand all possible weather conditions present throughout the year on the Iowa State University campus. These include extreme heat and cold, precipitation, also 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

5 The server/client system must run off of standard 110 V AC power, as well as have the ability to run off of battery backup in case of main power failure.

 Hardware Requirements The server unit stores a single database for all client units in a single parking area. The server must use redundant processing and storage capabilities to decrease the chance of failure. The client unit will use only a single processor and have considerably less storage than the server. The client 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.

 Machine Size Requirements The external housing unit must be large enough to hold all the hardware pieces securely, but should not be so large as to be visually obtrusive.

 Server-system hardware using dual processor design A system of this type will utilize a dual-processor scheme that allows the second processor to automatically carry the load should the first processor fail. It has redundant storage capability with its two sets of storage memory. This scheme helps prevent downtime so that the unit can continue operating even after a minor hardware failure.

 Programming Languages The following programming languages have been used by previous teams.

o MySQL Using MySQL will allow easy creation of the central database, and offer cross-platform compatibility between Windows and Linux. o C/C++ Using the C language will allow for creation of a modular, easily modifiable, software program.

 Communications hardware using wired Ethernet

Wired Ethernet communication shall be used in the current prototype and the second client unit that the May06-02 team will construct. Alternative technologies may be researched by that team.

6 8.3. Approaches Considered and Used

Previous groups had already selected or recommended most of the technical approach considerations before the Dec05-02 team became part of the project team, as the server and client units had finished initial development. This team’s specific technical considerations were in how to support the unit and how to replicate it.

The server unit is dual-processor redundant server unit, 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 client units are single processor units. They must support the user interface peripherals: coin acceptor, printer, keypad, and LCD screen.

The software package must be robust and feature-filled. C++ will be used to implement this package. C was also considered but C++ chosen for better object-oriented support. For the client, the development environment will be Windows XP Embedded and Linux for the server unit. The database system, located in the server unit, will be MySQL, which offers cross-platform compatibility between the server and client.

This team’s support for the unit will be a continuation of these previously decided technical approaches. Replicating the unit will require getting a bill of materials, ordering them, and constructing the new unit installing software as necessary.

A new keypad interface was desired for the new parking meter units. It was necessary that the interface be readily available and easy to use. The Dec05-02 team has conducted research on different keypads and has selected one for use with all future parking meters built with the project team’s instructions. This keypad includes an adapter to convert directly to RS-232 serial transmissions, eliminating the need to reverse-engineer the adapter currently in place. The selection of this new keypad is reflected in the parts list in section 8.4.

8.4. Detailed Design

This section describes the detailed design that will be followed to construct the second prototype parking meter by the May06-02 team. Since the same servers will be used to support multiple prototype parking meters, the client unit is the only portion of the system that must be duplicated. Below is a block diagram of the hardware design of this system, which is used for user interaction.

7 Figure 8.2-1: Client unit hardware block diagram

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

Motherboard Via Epia 800 MHz motherboard Source: http://www.mini-box.com/ Cost: $99.00 Notes: Motherboard contains integrated processor. Additional needed features include onboard Ethernet, USB ports, serial port and additional serial port header.

Case & Power Supply Travla C158-90W Black Source: http://www.caseoutlet.com/ Cost: $128.00 Notes: Any mini ITX case will do.

RAM Viking 256 MB PC133 RAM Source: http://www.newegg.com/ Cost: $32.95 Notes: Any ram will do.

8 LCD Module Matrix Orbital LCD4041 Source: http://www.matrixorbital.com/ Cost: $118.00 Notes: This LCD module was selected because it provided a 4 line by 40 character display, as well as a serial input. No drivers needed.

Solid State Memory M-Systems MDI1151-D512 512MB flash module Source: http://www.tri-m.com/ Cost: $81.00 Notes: Serves as the Hard disk. No moving parts and it uses an IDE interface.

Disk-On-Chip Power Cable M-Systems P/N DOC-IDE40-CABLE Cost: $2.00 Source: http://www.tri-m.com/ Notes: Power cable for the solid-state memory.

16-Key Illuminated Graphic Keypad Storm Interface P/N MGR1573-ND Source: http://www.digikey.com/ Cost: $70.23 Notes: This is the new keypad selected by the Dec05-02 team.

Keypad to RS-232 Interface Board Storm Interface P/N MGR1602-ND Source: http://www.digikey.com/ Cost: $69.73 Notes: This interface card converts the electrical output of the keypad into RS-232 serial format.

Button Legend Set B Storm Interface P/N MGR1551-ND Source: http://www.digikey.com/ Cost: $2.58 Notes: This set of button symbols for the keypad contains numbers, arrow keys, and other button denotations the parking meter uses.

Keypad Interface Board Enclosure Serpac P/N SR133B-ND Cost: $6.43 Source: http://www.digikey.com/ Notes: Any enclosure of this size will do.

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. Connects to the coin acceptor controller (MDB2PC).

9 Coin acceptor controller Upstate Networks Incorporated MDB2PC Source: http://www.upstatenetworks.com/mdb/ Cost: $300.00 Notes: This converts the MDB protocol outputted from the coin acceptor to serial data that the computer can read. No drivers needed.

Coin acceptor controller enclosure SR171B-ND black plastic project enclosure Source: http://www.digikey.com/ Cost: $9.73 Notes: Any 4.88 X 6.88 X 1.5 or similar enclosure will do.

Thermal Printer Fujitsu FTP-639MCL Infinite Peripherals Printer Source: http://www.ipcprint.com Cost: approx. $350.00 Notes: Connects to the client via USB. Drivers are located at http://seniord.ece.iastate.edu/may0502/printer/W2K_XP_Fujitsu-1.03.10.zip

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

Battery Backup (UPS) APC BK650MC Source: http://www.newegg.com/ Cost: $80.00 Notes: This model was selected because of dimensions, but any UPS will do.

Outer Case Source: Provided by DPS from an older parking meter unit. New case must be manufactured – this is out of the scope of the Dec05-02 team’s project activity. Cost: Unknown

10 Figure 8.2-2: Flowchart for customer functions software

11 Figure 8.2-3: Flowchart for administrator functions software

8.5. Implementation Process

This project team did not have any significant implementation activity. The construction of the second client unit has been deferred to the May06-02 team due to parts ordering issues, and the construction of the primary unit was completed before the Dec05-02 team came on to the project. This team’s primary activities have been in documentation, research, and testing.

8.6. End-Product Testing

This section describes the testing methodology used by the Dec05-02 team to test the primary server and client units and some preliminary results of this testing. The testing

12 methodology for the primary server/client unit once it has been delivered to the parking division is also discussed. Testing issues identified with the second client unit are also identified.

8.6.1. Testing Methodology

 Pre-field and Field Testing Testing must occur before the system is placed in the parking area.

o The existing client unit has been tested for full functionality in all user interfaces prior to placement in field. Testing included all user interfaces and all boundary conditions as well as extreme cases. Once proper operation has been verified, unit will be mounted semi-permanently for field-testing. As of the date of this report, issues with Windows XP Embedded licensing have prevented the team from field-testing the unit. o Field-testing will involve operation of unit in a ‘real-life’ non simulated environment for a specified period of time. The May06-02 team will work closely with DPS so as to ensure proper operation and timely fixes should any problems arise. o Continued testing will happen after the initial unit is installed. A duplicate unit will be constructed and will be kept in the team’s testing room. This unit will be used to re-create issues found with the unit being field-tested and to test solutions to any software bugs that may be discovered in the field.

 Hardware Testing The second client unit will require thorough testing upon completion. Tests will be conducted to verify that the unit performs as required; specifically, it should perform identically to existing functional client unit. Testing will be completed by as many people as possible, including all May06-02 group members. Tests will be well-documented to ensure timely fixing of any problems to be encountered.

 Software Testing Software will be installed, and must be tested to ensure proper operation. The software will be tested against existing implementations to ensure uniform operation between units.

8.6.2. Testing Results Working with the May05-02 and May06-02 teams, five major rounds of software testing have been completed over the Dec05-02 team’s tenure on this project. These testing rounds have each identified bugs with the parking meter software. As of the date of this report, all known bugs within the parking meter software have been fixed. Regression testing was used to verify that the software changes made fixed the bugs in question. There is no bug-free software. However, the Dec05-02 has team has done everything in

13 its power to ensure that no major bugs exist within the code when the primary server/client unit is delivered to the parking division.

As of the date of this report, testing of the various hardware components inside the primary server/client system (battery backup, heating element, etc) is in progress.

8.7. Project End Results

As of the date of this report, the primary server/client parking meter system has not yet been delivered to the parking division. However, the Dec05-02 team feels optimistic that the parking meter system will be delivered by the end of the Fall 2005 semester. Once the team receives a licensed copy of Windows XP Embedded, the team will be able to deliver the completed parking meter to the parking division for testing within three days. The Dec05-02 team has generated a comprehensive parts list for a second parking meter system, and parts have been ordered for this system. The May06-02 team will continue with building the second client unit in the Spring 2006 semester.

9. Estimated Resources and Schedules

This section describes an estimate of the resources required to complete this project. Tables 9-1 and 9-2 show the original and revised projections of team member effort for the following tasks:

9.1. Estimated Resources Task 1 – Project Familiarization Task 2 – Testing of Current Unit Subtask 2.1 – Writing Test Cases Subtask 2.2 – Executing Test Cases Task 3 – Preparation and Installation of Unit Task 4 – Support Unit Task 5 – Documentation for 2nd Unit Subtask 5.1 – Parts List Subtask 5.2 – Cost Estimate Subtask 5.3 – Alternative Parts List Task 6 – Build 2nd Unit Subtask 6.1 – Ordering Parts Subtask 6.2 – Hardware Assembly of 2nd Unit Subtask 6.3 – Installation of Software Subtask 6.4 – Software to Allow Multiple Client Units Subtask 6.5 – Testing of 2nd Unit

14 Table 9.1 – Personnel Effort Requirements (original) Name Task Task 2 Task Task Task 5 Task 6 TOTAL 1 2.1 2.2 3 4 5.1 5.2 5.3 6.1 6.2 6.3 6.4 6.5 Brandon 37 0 36 27 9 21 18 29 17 3 0 0 26 223 Crist Seth 38 0 35 23 14 27 16 19 17 0 8 9 18 224 Graber Daniel 35 31 35 24 3 9 12 8 13 0 9 7 27 223 Helvick Jeremy 36 0 37 27 9 22 27 23 14 3 0 0 13 211 Meeks Erik 39 43 38 12 8 9 7 17 22 0 9 11 23 238 Sautter TOTAL 185 84 181 113 43 88 80 96 83 6 26 27 107 1119

Table 9.2 – Personnel Effort Requirements (actual used as of 11/10/05) Name Task Task 2 Task Task Task 5 Task 6 TOTAL 1 2.1 2.2 3 4 5.1 5.2 5.3 6.1 6.2 6.3 6.4 6.5 Brandon 27 4 13 27 9 8 2 1 0 0 0 0 0 91 Crist Seth 26 3 15 23 14 20 3 1 0 0 0 0 0 105 Graber Daniel 28 31 25 24 3 15 31 8 7 0 0 0 0 172 Helvick Jeremy 27 12 18 27 9 11 4 1 0 0 0 0 0 109 Meeks Erik 29 33 16 12 8 13 7 1 0 0 0 0 0 119 Sautter TOTAL 137 83 87 113 43 67 47 12 7 0 0 0 0 596

Table 9.2 shows the estimated actual effort invested by each team member. Task 6 is mostly omitted due to the tardiness in subtask 6.1: ordering parts, which has set all subtasks for task 6 back until parts arrive.

Tables 9.3 and 9.4 show the estimated additional resources required for the project. 9.3 gives the initial projections, while 9.4 shows the actual known requirements as of 11/10/05.

15 Table 9.3 – Other Resource Requirements (original) Equipment and Other Resources Item Team 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 9.4 – Other Resource Requirements (actual) Equipment and Other Resources Item Team Hours Cost Motherboard/Processor 1 0 $99.00 RAM 1 0 $32.95 Storage 1 0 $81.00 Motherboard/Processor 2 0 $99.00 RAM 2 0 $32.95 Storage 2 0 $81.00 LCD 0 $118.18 Keypad 0 $148.97 Coin Acceptor Controller 0 $149.00 UPS Battery Backup Unit 0 $48.49 Housing 0 $0.00 Project Poster 10 $25.00 TOTAL 10 $915.54

Tables 9.5 and 9.6 give the financial resources required for the project. Table 9.5 gives the preliminary estimates for financial resources and Table 9.6 gives the known financial resources as of 11/10/05. Estimates for labor are also included in the tables. Cost of labor is estimated at $11.00/hour. Figures 9.2-1 and 9.2-2 show the projects original and revised schedules. Figure 9.2-1 shows the schedule by task, and Figure 9.2-2 shows it by milestone.

16 Table 9.5 – Financial Requirements (original) Item Cost Parts and materials Motherboard/Processor 1 $150.00 RAM 1 $50.00 Storage 1 $200.00 Motherboard/Processor 2 $150.00 RAM 2 $50.00 Storage 2 $200.00 LCD $75.00 Keypad $100.00 Misc. Buttons $50.00 Printer Interface $120.00 Ethernet Switch $57.00 UPS Battery Backup Unit $100.00 Housing $100.00 Project Poster $50.00 Services Shipping and handling $50.00 Binding $30.00 Equipment subtotal (per unit) $1,532.00 Labor ($11.00 / hour) Brandon Crist $1,265.00 Seth Graber $1,210.00 Daniel Helvick $1,375.00 Jeremy Meeks $1,320.00 Erik Sautter $1,375.00 Labor subtotal (per unit) $6,545.00 TOTAL (with labor per unit) $8,077.00 TOTAL (2 Units) $16,154.00

17 Table 9.6 – Financial Requirements (actual) Item Cost Parts and materials Motherboard/Processor 1 $99.00 RAM 1 $32.95 Storage 1 $81.00 Motherboard/Processor 2 $99.00 RAM 2 $32.95 Storage 2 $81.00 LCD $118.18 Keypad $148.97 Coin Acceptor Controller $149.00 UPS Battery Backup Unit $48.49 Housing $0.00 Project Poster $25.00 Services Shipping and handling $50.00 Binding $30.00 Equipment subtotal (per unit) $995.54 Labor ($11.00 / hour) Brandon Crist $1,001.00 Seth Graber $1,155.00 Daniel Helvick $1,892.00 Jeremy Meeks $1,199.00 Erik Sautter $1,309.00 Labor subtotal $6,556.00 TOTAL (with labor) $7,551.54

18 Figure 9.2-1. Original and Actual Project Schedules by Task

Figure 9.2-2. Original and Actual Project Schedule by Milestone

10. Project Evaluation

This section describes our project objectives and assesses whether or not, and to what level, they were met.

 Project Familiarization The familiarization phase of this project has been completed and fully met. The project team worked hard for its first semester to become familiar with the requirements of the project and functional details of the software through the

19 team’s efforts writing and executing tests. Also, this semester required more familiarization with the code and hardware, but we successfully completed that and are now quite familiar with how our project works.

 Preparation and Installation The preparation and installation milestone of this project has been partially completed. After a thorough batch of testing last semester, also more testing and bug fixing this semester, the unit hardware and software has been fully implemented. Further on-site testing must take place with the possibility of software changes to fix bugs, meaning that there is more effort in this task that must take place before the project is finished. The team’s preparation efforts included fixing any software bugs that were found and setting up the unit parameters correctly after reinstalling components such as Windows XP Embedded. Installation will be done by an ISU facilities team, and that is expected to take place by the end of the semester, meaning the team projects this task to be completed successfully by the end of the semester. Given that the remaining tasks for this milestone include securing a Windows XP Embedded license and the installation of the unit, the task is approximately 95% complete.

 Testing Testing of the project is a milestone that has been partially met. The team developed a full test suite to provide coverage for every software requirement in the software functional description. The team ran these tests multiple times and currently over 90% of the steps pass. The team’s work this semester continues to fix any further software or test errors that are causing these few failures. After this, testing moves to an on-site basis. The unit will go into the Armory parking lot to be tested in the field, with feedback from users and the client being offered. This has not yet been completed. The team’s testing efforts are not complete, but a majority of the testing effort has been completed through the careful writing of the tests to the software functional description. Testing effort is roughly 80% complete, meaning this objective has been partially met.

 Support Support is a milestone that has not been attempted. The definition of this milestone is to fix any issues that come up during on-site testing. The team has not put the unit out for that yet, so no support effort has yet been possible.

 Documentation For Second Unit The documentation for the second unit includes a parts list, cost estimate, and alternative parts list. The alternative parts list is necessary for compatibility reasons. The original unit contained certain parts that were not bought and would be hard to replicate. Researching and providing a list of alternative parts that provide easy replication was deemed a necessary task. The team has completed the parts list and cost estimate. The alternative parts list is incomplete. Therefore this milestone is roughly 90% met.

20  Build Second Unit Building of the second unit has been partially completed. After many delays, the team just recently received parts for which an order was placed early in the semester. The May06-02 team had been planning to focus much of their effort on building this unit, while this team focused on the task of preparation and installation, but this did not come to be so because of parts ordering delays. As an effect, this milestone has not been attempted at this time. The team now has our parts, but preparation and installation are the team’s priority. The second unit will be assembled by the May06-02 team.

 Overall Evaluation With the criteria of “great success”, “success”, and “not a success,” the team believes this project has been a “success”. The team have not completely reached all our milestones, but the team has made progress and have mostly met its objectives, with expected further progress yet this semester. Whether the team gets the unit out for lot testing is dependant on a product licensing issue for Windows XP Embedded that is currently in the hands of the team’s project advisor. Difficulties caused by this issue have been the reason the team has not gotten the unit out for testing, due to unforeseen expenses involved in getting a product license. The current team inherited this problem, but must bear responsibility for the difficulties and lost time it has caused the team. It and the parts ordering delay ultimately reflect on the team’s performance, but we believe this project has still been a “success” due to the team’s good performance on other objectives and excellent team work.

11. Recommendations For Additional Work

This section will outline what further work needs to be done to complete this project.

 Continued Implementation The next team will continue testing the unit by placing the unit in the parking lot and fixing any bugs and changing requirements per client feedback. Assembly of the second client unit will also be taking place. Any more necessary updates to the software functional description and other documentation for the client will need to take place.

 Commercialization This product is designed for the ISU Parking Division, and as such will not be commercialized. Thus, no commercialization plans will be necessary.

12. Lessons Learned

This section will outline what the team has learned from this project. It goes into detail about what did and did not go well, the knowledge the team has gained, and any changes the team would make if it had to do the project over.

21  What Went Well The team feels our teamwork was exemplary. Every task that needed to be done got done, and it happened through everyone stepping up at different times and taking the lead to get certain tasks done. Whether it was testing, documentation, or another task, everyone contributed almost equally to the project and gave a good effort. Also, team relations have been good. There has been no tension within the team, and the team members have all become closer acquaintances through their time working together. Also, the team believes its test writing went very well. The team had members who had worked on testing in a corporate environment who could lead in producing tests that thoroughly verified whether project requirements were met. Documentation of test efforts also went well, allowing those in charge of fixing bugs to be able to reproduce errors and more easily fix software problems.

 What Did Not Go Well There were a few things in this project that did not go well. Much of the knowledge of the software was concentrated in the previous team, and so efforts by the team to edit software were hindered by the learning curve of not understanding the software. Also, the issue the team uncovered with Windows XP Embedded licensing caused large delays. For reasons due mainly to vague communication of the problem to the technical expertise the team enlisted to help, this issue did not get solved as quickly as it should have. Also, other technical issues sprang up that were largely hardware related, however beyond the team’s control. A connector for our LCD broke, needing over a week to get fixed. Server issues also occurred relating to a broken power cable. Though the majority of the project tasks went well, the few that did go poorly cost the team a lot of time in its second semester.

 Knowledge Gained The knowledge the team gained from this project contained elements of both technical and non-technical knowledge. In the arena of technical knowledge, what the team gained was a better understanding of software requirements and implementing them, developing software and hardware, working with a system that is pre-existing and accounting for the associated learning curve, as well as knowledge of Windows XP Embedded, Linux, C++, and MySQL. Finally, a wealth of testing knowledge was gained. All of these are important in a real world corporate environment. Non-technical knowledge gained was management of time and tasks, working in a team environment, designing a poster, writing documentation, and reading documentation from other teams.

 Things To Change If the team could do this project over, there are certain things it would change. The team would have been more diligent in attacking the Windows XP Embedded licensing issue. The team assumed that it would be pretty simple to handle, but given the great cost that is associated with fixing the issue it has caused delays which were not expected when the team thought the solution was simple. Getting

22 to the bottom of this problem sooner could have saved the team some valuable time during its second semester. The team would have also liked to change some decisions of components that were chosen for the project prior to the current team being on the project. With prices lower on some types of components, wthe team feels that it could have lowered the cost of the unit with some redesign, but since the project had already come a long way this was not prudent in order to meet deadlines and get the product to the client in a reasonable time frame.

13. Risk Management

This section will discuss risks that we planned for and encountered, and the team’s success in dealing with them.

13.1 Anticipated Risks These risks are risks that the team planned for in the management of this project:

 Loss Of Team Member The team planned for potentially losing a team member by communicating well with one another, and making certain everyone was well involved. The team usually assigned multiple team members to each task to make sure there was not too much of a knowledge imbalance on the team. The team also have used its members’ notebooks to write down notes that could be recovered in the case that a team member was lost.

 Hardware Failure To plan for the risk of hardware failure, the team has had the list of parts close at hand to quickly order new hardware.

 Parts Procurement Delays The team planned for parts taking longer than expected to arrive after placing the order for the second client unit. This was done by being sure to place the parts order far ahead of the time that the team would actually need the parts.

 Data Loss Data loss is another risk the team planned for. The team has used a source control system to keep multiple versions of the parking meter software code, as well as having multiple electronic copies of the code and all documentation.

13.2 Anticipated Risks Encountered Certain risks that were anticipated were in fact encountered in the project. Here, these risks will be explained, and how successfully the team’s risk management was in dealing with them.

 Parts Procurement Delays

23 Due to miscommunications regarding parts order forms, and how large the order was, the team did encounter a delay in getting the hardware wit had ordered. The team’s risk management plan was successful in this, however, because the team has faced lost project time as an effect of this delay.

 Data Loss The team experienced effects from the risk of data loss after the previous team graduated and the team members moved away. A certain team member in particular had a lot of information that he was offering to make available to the team if it needed it. However, due to a computer problem, that team member formatted their hard drive, wiping out that information. However, due to the current team’s risk management plan, the team had access to backups of all that information, so it only caused a brief delay in making sure the team was restoring the most up to date data.

 Hardware Failure The interface card for our coin acceptor failed at one point in the project. Having the details close at hand to order a new one quickly, according to the team’s risk management plan, was instrumental in the project continuing to move forward in testing at that stage. The team also had a connector break on the LCD unit. Looking closely at the product details allowed the team to see how it could be fixed, and the team forwarded that responsibility to the proper expertise quickly. Finally, after a power cable for a disk-on-chip unit broke, the team was able to put a part order out quickly to remedy that issue.

13.3 Unanticipated Risks Encountered This project also faced one large unanticipated risk. Good project management requires good planning, but also adapting to unforeseen difficulties. Here are the unanticipated risks the team encountered and how we dealt with them.

Windows XP Embedded Licensing Coming onto the project already in process, the team was presented with certain effects of decisions that had been previously made. One of these was the use of Windows XP Embedded. The team mistakenly assumed that a previous team had researched and taken care of any licensing issues with the software, but this was not the case. The licensing for the product turned out to be very expensive for a senior design project, and attempts by the team and its project advisors to remedy this situation has caused substantial delays. After discovering the issue, the team alerted its project advisor as soon as was possible, and did research on how to correct the licensing issue. The team acted quickly on the issue with as much action as it could take, but it has still caused great delays.

13.4 Resultant Changes Due to the unanticipated risk the team encountered, the team has made changes to its management of risks. The team has since gone back and carefully reviewed many of the processes that will make the parking meter system works, such as the installation of all components and software to make sure there are no other latent issues that the team is

24 unaware of because it was initially handled by a different team. This has been successful in working out some kinks with building and installing the final parking meter software, as the team has been able to practice the installation and make sure it will be smooth when the unit is to go out into the parking lot.

14. Project Team Information This section includes information about the client, faculty advisors, and student team members 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 [email protected]

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 [email protected] [email protected]

Team Members

Brandon Crist Seth Graber Electrical Engineering Computer Engineering 9126 Buchanan Hall 2132 Sunset Dr Ames, IA 50013 Ames, IA 50014 515-572-6140 515-296-1845 [email protected] [email protected]

Daniel Helvick Jeremy Meeks Electrical/Computer Engineering Electrical Engineering 263 N Hyland #13 1133 Frederiksen Ct Ames, IA 50014 Ames, IA 50010 515-460-5069 515-572-7669 [email protected] [email protected]

25 Erik Sautter Computer Engineering 345 Linden Stewart Ames, IA 50013 515-231-0796 [email protected]

15. Closing Summary

This project attacks a very real problem faced by the administration at Iowa State University. Parking space is a problem that has been faced in an increasing measure over the last few years, and attempts to provide and monitor parking by building lots with multiple stall parking meters have led to problems for the ISU Parking Division. This project provides a solution to the parking meter issue by implementing at a low cost the features that the Parking Division has specified necessary to provide flexible and efficient parking regulation enforcement. Being developed for easy replication, this project will allow the Parking Division the expansion in its parking enforcement it needs for the future, with the ability to install the parking meter unit in new parking lots.

This project has been continuing for a time, and in that time it has seen successes and failures, both before this team became a part of the project and since the time it has been on it. Though it has progressed slower than the team have expected due to a software licensing issue, the team has taken much care to test and fix the software of the unit, steering the project in the right direction and allowing it to be finished as a robust product that will work well at meeting the requirements that the ISU Parking Division has for it.

16. References

Prototype Parking Meter – Phase 4 Design Report – Dec05-02 April 13, 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