Prototype Parking Meter – Phase 5

Final Report

Project team: May06-02

ClientIowa State University Parking Division

AdvisorsJohn W. Lamont, Ralph E. Patterson III

Team MembersMichael Arns, Kristi Gavin, Mikael Nielsen

Ben Quach, Nichole Wittry

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.

March 31, 2006

1

Table of Contents

Item Page

List of Figures iiiList of Tables ivList of Definitions v1. Executive Summary 1

1.1 Need for Project 11.2 Actual Project 11.3 Previous Accomplishments 2

1.4 Present Accomplishments21.5 Required Future Activities 3

2. Acknowledgement 33. Problem Statement 3

3.1. General Problem Statement 33.2. General Solution Approach 4

4. Operating Environment 45. Intended Users 56. Intended Uses 57. Assumptions 68. Limitations 69. Expected End Product and Other Deliverables 6

9.1. Multi-space Parking Meter System 79.2. Complete Parts List and Assembly/Setup Instructions 79.3. Support Plan 79.4. End-user documentation 79.5 Instruction Sign 89.6 Project Plan 89.7 Design Report 89.8 Final Report 8

10. Project Approach and Results 810.1 End-Product Functional Requirements 810.2 Design Requirements and Constraints 910.3 Approaches Considered and Used 1010.4 Detailed Design 1110.5 Implementation Process 1510.6 End-Product Testing 16

10.6.1 Testing Methodology 1610.6.2 Testing Results 17

10.7 Product End Results 1811. Estimated Resources and Schedules 18

11.1 Estimated Resources 1811.2 Schedules 25

2

Table of Contents (cont.)

12. Project Evaluation 2613. Commercialization 2814. Recommendations for Additional Work 2815. Lessons Learned 2816. Risk Management 29

16.1 Anticipated Risks 2916.2 Anticipated Risks Encountered 3016.3 Unanticipated Risks Encountered 30

16.3.1 Windows XP Embedded Licensing 3116.4 Resultant Changes 31

17. Project Team Information 3118. Closing Summary 3219. References 33

3

List of Figures

Item Page

Figure 10.2-1 – Client Unit Hardware Block Diagram 11Figure 10.2-2 – Flowchart for Customer Functions Software 14Figure 10.2-3 – Flowchart for Administrator Functions Software 15Figure 11.2-1 – Original (blue), Revised (red), and Actual (green)

Project Schedules 25

4

List of Tables

Item Page

Table 11.1-1 – Personnel Effort Requirements (original) 19Table 11.1-2 – Personnel Effort Requirements (revised) 19Table 11.1-3 – Personnel Effort Requirements (actual) 19Table 11.1-4 – Other Resource Requirements (original) 20Table 11.1-5 – Other Resource Requirements (revised) 20Table 11.1-6 – Other Resource Requirements (actual) 21Table 11.1-7 – Financial Requirements (original) 22Table 11.1-8 – Financial Requirements (revised) 23Table 11.1-9 – Financial Requirements (actual) 24

5

List of Definitions

A

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

B-C

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

D

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

E

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

F-G

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

H-I-J-K-L

Linux: An open-source operating system.

M

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

N-O-P-Q-R-S-T-U-V-W

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

6

List of Definitions (cont.)

X-Y-Z

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

7

1. Executive Summary

The following is a summary of the Prototype Parking Meter – Phase 5 senior design project. It will briefly cover the need for the project, the actual project, previous teams’ accomplishments, present team’s accomplishments, and the work that has yet to be completed to finish the project.

1.1 Need for Project

Traditional parking meter systems require one unit for every parking spot. In contrast, two of the existing lots at Iowa State have been installed with computerized parking meter units that are able to accept money, print receipts, and track multiple spaces from one or two locations. This setup provides advantages over the traditional parking meters, such as the ability to monitor the entire lot and collect money from one location.

However, there are still several problems with the current Iowa State parking meter system. The current parking meter units lack the ability to communicate with one another. Also, if a user wishes to add time to a parking space for which they have already paid, they must return to the same exact parking meter unit. The current parking meter units are difficult to program and require a specialist from a company that no longer exists. Finally, the cost of a new parking meter system to replace the current system and overcome these problems is too expensive for the university to consider. The cost of each new programmable unit begins at $10,000 and rapidly escalates to more than $75,000 as features are added.

1.2 Actual Project

By collaborating with the ISU Parking Division, the objective of this project is to develop an improved parking meter system to monitor the pay-for-parking lots at Iowa State University. This system will be similar to the current pay-for-parking lots implemented on the Iowa State University campus, but will allow for more functionality and flexibility. The new system will also be more affordable, user-friendly, and easier to maintain.

Commercial systems on today’s parking meter market implement single processor designs. Our approach to the problem was to develop a parking meter system that implements multiple units, all of which will communicate with a central parking meter server though a set of master/slave connections. This allows communication between units, and for users of the lot to be able to add time via any parking meter unit. The new system will also allow DPS parking enforcement officers to receive a single list of lot activity instead of multiple lists. In addition, the system will have a redundant central

8

processor and additional memory, which will create a much more robust solution than is currently available.

The new parking meter units will have an easy to use interface that will make them more user friendly, and allow DPS to effectively maintain the parking meter system. Finally, the system will be implemented with standard computer hardware, which will make duplication easier and decrease the cost of construction and maintenance of the parking meter units.

1.3 Previous Accomplishments

Not including the current May06-02 team, there have been four previous teams that have worked on the prototype parking meter project.

The May04-02 team created a complete problem definition for the project containing uses, assumptions, limitations, functional requirements, management procedures, and success evaluation criteria. They also researched hardware and software to meet the project functional requirements.

The Dec04-02 team selected hardware and software for the project implementation, and completed the project design. They also defined and functioning product that would meet the design requirements, specifications and client needs.

The May05-02 team completed the creation, customization, and installation of Windows XP Embedded to the slave computer’s storage device. They also completed the software classes and functional description, and implemented the software classes used. The May05-02 team also installed and configured the SQL database for the master units, and performed some basic customer testing and bug fixing.

The Dec05-02 team completed a parts list for a second prototype slave unit, wrote a formal test plan and executed test cases, and resolved code problems and hardware issues with the prototype unit.

1.4 Present Accomplishments

This current May06-02 project team assisted in the continued testing of the prototype unit, developed a sign for instructing users out in the parking lot, ordered parts for a future second prototype slave unit, began construction on the second prototype slave unit, resolved a runtime license issue with the XP Embedded software, and created a detailed plan for technically supporting the new parking meter system once it is placed into the Armory parking lot. This project team will have the new parking meter system installed in the Armory lot for customer testing by the end of the spring 2006 semester.

9

1.5 Required Future Activities

Future prototype parking meter teams will have a few more activities to accomplish. They must provide continuing and effective support of the new parking meter system once it is installed in the Armory parking lot. They must also complete construction on a second parking meter slave unit, and develop a simulation system capable of debugging and solving problems from the parking meter lab. Lastly, a major activity will be to develop a method of loading software fixes and changes to the parking meter system by linking a laptop to the parking meter units.

2. Acknowledgement

The project team would like to thank the following people for their time, ideas and financial contributions to the project: Doug Houghton of the Department of Public Safety, Iowa State University, the May04-02, Dec04-02, May05-02, and Dec05-02 electrical/computer engineering senior design teams, the Mechanical Engineering 466 students, and Jason Boyd. The project team would also like to acknowledge our project advisors, Dr. John W. Lamont, and Professor Ralph Patterson III for their advice and guidance with the project.

3. Problem Statement

The following sections will provide a general overview of the problem to be addressed, and how this project will provide a solution for it.

3.1 General Problem Statement

Availability of parking on or near campus has become a concern at Iowa State University. In an attempt to control the parking lot congestion, the University has chosen to install parking meter systems. Traditional parking meter systems require one unit for every parking spot. In contrast, two of the existing lots at Iowa State have been installed with centralized parking meter units that are able to accept money and track multiple spaces from one or two locations. This setup provides advantages over the traditional parking meters, such as the ability to monitor the entire lot and collect money from one location.

However, there are several problems with the current Iowa State parking meter system. The current parking meter units lack the ability to communicate with one another. This means that when the lot is checked for offenders, each parking meter unit must be checked individually. Also, if a user wishes to add time to a parking space for which they

10

have already paid, they must return to the same exact parking meter unit. Finally, the lack of communication between the parking meter units means that if one unit is disabled, all of its stored data is lost.

Another problem is the current parking meter units are very difficult to program. DPS has requested the ability to program in university holidays, as well as change the hourly rates. The company formerly responsible for doing this is now out of business, thus making it extremely difficult and expensive to fix problems that may need immediate attention.

3.2 General Solution Approach

This project will attempt to solve these problems by providing an improved parking meter system to monitor the pay-for-parking lots. This system will be similar to the current pay-for-parking lots implemented on the Iowa State University campus, but will allow for more functionality and flexibility. The new system will also be more affordable, user-friendly, and easier to maintain.

The parking meter system in development may be implemented with many units, all of which will communicate with a central parking meter server though a set of master/slave connections. Users of the lot will be able to add time via any parking meter unit. The new system will also allow DPS parking enforcement officers to receive a single list of lot activity. In addition, the system will have a redundant central processor and additional memory, which will create a much more robust solution than is currently available.

The new parking meter units will have an easy to use interface that will make them more user friendly, and allow DPS to effectively maintain the parking meter system. Finally, the system will be implemented with standard computer hardware, which will make duplication easier and decrease the cost of construction and maintenance of the parking meter units.

The May04-02 senior design team completed the first phase of the project. This group completed much of the initial design work. The second group, Dec 04-02, completed the design and partly implemented a prototype unit. The third group, May05-02, was responsible for completing the prototype unit and producing a user’s guide for the system. The Dec05-02 team is responsible for testing the prototype unit, and producing a parts list and assembly/setup instructions. This team, May06-02, will be responsible for assisting in the continued testing of the prototype unit, building a second slave parking meter unit, and developing a parking meter simulation system for use within the lab. The May06-02 team will also design an instructional sign to assist users of the parking meter, create a user’s manual for DPS, and rewrite the test cases to account for the new standardized rates given by DPS.

4. Operating Environment

11

The new parking meter system will be installed in the north-east portion of the parking lot west of the Armory building at Iowa State University in Ames, IA. It must be able to withstand extreme temperatures ranging from -30° F to 115° F. The parking meter units will also be able to deal with all forms of precipitation such as rain, snow, and hail.

The parking meter units will be used on a regular basis, and often by users that may treat the unit roughly. Because of this, the units must be durable and designed to withstand extended users. Finally, because the units will be located on a college campus, it must be sturdy, and resistant to attempts at vandalism.

5. Intended Users

There are three classes of users will use the system:

First class: The Customer. This includes the following categories of users:

o College students at Iowa State University.o Faculty and staff of Iowa Sate Universityo Visitors to the Iowa State University campus

Second class: The Administrator. The Iowa State University Department of Public Safety

student employees. They need additional functionality in order to monitor the parking lots.

Third class: The Supervisor. This user will have to access to all the features available to

supervisor class.

6. Intended Uses

The system will have three classes of user (see above).

For the first class of users, that park in the lot, the system will: Allow parking spaces to be paid for by a specifying an amount of time, specifying

an end time, or inserting money. Allow time to be added to any parking space from any unit in lot. Print a hard-copy receipt if the user desires.

For the second class of users, the Department of Public Safety, the system will: Allow DPS to monitor paid and unpaid parking spot in the lot. Allow DPS to gather parking lot usage statistics.

For the third class of users, the Department of Public Safety, the system will:

12

Allow DPS to monitor paid and unpaid parking spot in the lot. Allow DPS to gather parking lot usage statistics. Allow DPS to change hourly rates and set holidays. Allow users to add and delete second and third class users.

7. Assumptions

The list below is all the assumptions that the group is taking into account when designing the system:

The lot size will contain no more then 1000 spaces. The units will not provide change to users. AC power will be provided to the unit. The units will only accept nickels, dimes, and quarters as payment.

8. Limitations

The list below is all the limitations that the group is taking into account when designing the system:

The unit must withstand Iowa outdoor conditions. The user interface will be compact and easy to use. The system must provide all of the capabilities of the current system. The system must allow for different rates, time of day, and holidays rates. The units must allow users to add time to their current amount of time. The hardware unit must print receipt upon request. The hardware unit must provide the current payment status of the lot for parking

enforcement. The server unit must consist of two redundant processors. The server unit must have redundant storage. The server unit must accept connections to multiple slave units. The server unit must continue to run in the event that one of the processors fails or

one of the storage units is corrupted. The unit must continue running on backup power if the main power supply fails. DPS must be able to change rates and holidays without outside assistance.

9. Expected End Product and Other Deliverables

The end products for this project will be a fully functional server/client multi-space parking meter system, a secondary client unit in production by the Dec06-02 team, a cookbook containing assembly/setup instructions for subsequent units, a sign with a list of instructions telling customers how to use the unit, a complete parts list, and a support plan for the master/slave unit once it is in use. Also, documentation on the basic functions of the parking meter system will be made available to DPS so that their employees can learn how to use the system.

13

9.1 Multi-space Parking Meter System

This system will consist of one or more client computers connected to a central server computer. The system will be capable of handling up to 1000 parking spaces. The server unit will store all of the parking lot information. The client unit(s) will retrieve this information and act as the interface from which parking time is purchased and administrators and/or supervisors can update pay rates, change parking schedules and manage the parking lot. A secondary client unit will be built using the parts list and assembly/setup instructions described below. It will then be tested and supplied to DPS by the Dec06-02 and future senior design teams. These units will have a fully licensed copy of Microsoft Windows XP embedded that will allow them to run continually without expiration.

9.2 Complete Parts List and Assembly/Setup Instructions

The parts list is a document containing a complete list of hardware parts needed to build either a client or a server parking meter unit. This list has changed from previous semester’s list due to former parts no longer being available. The team was able to find parts made by the same company with the same functionality, and the list was updated to reflect these changes. The assembly/setup instructions are contained in a cookbook that details the steps required to assemble the hardware for a server or client unit and to correctly set up the software to run the parking lot application. This documentation is meant to allow the building of subsequent parking meters using the same interchangeable, cheap, easy-to-acquire parts.

9.3 Support Plan

Once the unit is completed and put into use for monitoring Iowa State University parking, problems may be encountered. In the event that the system fails or is not working properly, the Parking Division will need to have a way to get the problem solved as soon as possible. We have designed a strategy so that Parking Division can get a hold of the team and get the problem solved with minimal down time. This strategy will be discussed in more detail later in the document.

9.4 End-user Documentation

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

14

9.5 Instruction Sign

The current team has created a list of instructions for using the parking meter unit that covers the basic steps that allow users to purchase parking time. This is intended for customers who will be using the unit for the first time and allow them to be able to purchase time. The instruction list was delivered to the Iowa State Parking Division and is expected to be produced by them before the unit is placed in the lot.

9.6 Project Plan

The project plan is a document that defines that project and the plan for the completion of the project. It describes how design decisions were made for the project and defines the overall problem domain. This document was delivered in October of 2005.

9.7 Design Report

The design report is a document describing the overall design of the project. It is intended to provide all the details necessary for replication of the project by an independent team. This document was delivered in November of 2005.

9.8 Final Report

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

10. Project Approach and Results

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

10.1 End-Product Functional Requirements

The key functional requirements that the May06-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.

15

10.2 Design Requirements and Constraints

The entire project was done under the following constraints and considerations.

Weather ResistanceThe 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.

DurabilityThe 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 RequirementsThe server/client system must run off of standard 120 V AC power, as well as have the ability to run off of battery backup in case of main power failure.

Hardware RequirementsThe 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 also require the following parts: 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 RequirementsThe 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 DesignA 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 LanguagesThe following programming languages have been used by previous teams to create the parking meter software application.

16

o MySQLMySQL will allow easy creation of the central database, and offer cross-platform compatibility between Windows and Linux.

o C/C++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 is currently under construction.

10.3 Approaches Considered and Used

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

The approach used by previous teams to construct the server unit was to create a dual-processor redundant computer, running Linux on an x86 architecture. This off-the-shelf unit allows for reliability and quick and easy software development, as the architecture is common.

The approach used by previous teams to construct the client unit was to create a single processor computer that supported all of the user interface peripherals: coin acceptor, printer, keypad, and LCD screen.

The software package chosen by previous teams needed to be robust and feature-filled. C++ was chosen to implement this package. C was also considered, but C++ was chosen for better object-oriented support. For the client, the development environment was selected to be Windows XP Embedded. For the server unit, a distrubition of the Debian Linux operating system was selected. The database system, located in the server unit, was chosen to be MySQL, since it offers cross-platform compatibility between the server and client.

This team’s approach to designing the second client unit has already been determined in specifications drawn up by previous teams, and will closely mirror the method used to build the original unit. By following the same design for the second client unit, ease of maintenance and ease of replication will be preserved.

When determining how best to support the unit upon its installation into the parking lot, two methods were considered. The first method involved dealing with problems as they

17

would occur, on a case-by-case basis. This would require giving DPS an emergency phone contact number that they could use whenever a system failure occurred. Errors would then be debugged and corrected on-site by the parking meter team until a solution was found.

The second approach to supporting the unit would involve the implementation of an error notification and correction process. Using this process, problems would be reported by DPS via an online form that would automatically notify parking team members and advisors when a problem is found. Using the information supplied by DPS, coding errors would then be debugged using a simulation unit located in the lab. Once a solution is found, fixes would then be uploaded via a laptop connection to the on-site unit.

The May06-02 team chose to implement the second approach of supporting the unit, as it manages error notification in a more efficient manner, and allows corrections to be made without spending long hours on-site in potentially harsh weather conditions.

10.4 Detailed Design

This section describes the detailed design that will be followed to construct the second prototype parking meter, as well as the error reporting website.

For the second prototype parking meter, since the same servers will be used to support multiple prototype parking meters, the client unit is the only portion of the system that must be duplicated. Figure 10.2-1 is a block diagram of the hardware design of this system, which is used for user interaction.

18

Figure 10.2-1: Client Unit Hardware Block DiagramThe specific parts required for the client unit are listed below along with their purchase location and price.

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

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

RAMViking 256 MB PC133 RAMSource: http://www.newegg.com/Cost: $32.95Notes: Any ram will do.

LCD ModuleMatrix Orbital LK404-55Source: http://www.matrixorbital.com/Cost: $135.00Notes: This LCD module was selected because it provided a 4 line by 40 character display, as well as a serial input. No drivers are needed and includes an extended temperature range.

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

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

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

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

19

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

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

Coin acceptorCoinco Global 700Source: Iowa State DPSCost: $0Notes: DPS has extras of these on hand as they are used in the current parking meters. Connects to the coin acceptor controller (MDB2PC).

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

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

Thermal PrinterFujitsu FTP-639MCLInfinite Peripherals PrinterSource: http://www.ipcprint.comCost: approx. $350.00Notes: 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 SupplyInfinite Peripherals SPU-230-24IPAC power in 24VDC power outSource: http://www.ipcprint.com/Cost: $69.00Notes: Dual power supply. Provides power for both the printer and the coin acceptor / controller card.

Battery Backup (UPS)APC BK650MCSource: http://www.newegg.com/Cost: $80.00Notes: This model was selected because of dimensions, but any UPS will do. Use of this model will depend on further testing.

20

Outer CaseSource: The case for the second unit will be manufactured by the team’s mechanical engineering students. The outside appearance and interface will closely match that of the original unit. Cost: Unknown

Figure 10.2-2 and Figure 10.2-3 show the design of the customer and administrator menu options that will be available to system users via the system software application.

Figure 10.2-2: Flowchart for Customer Functions Software

21

Figure 10.2-3: Flowchart for Administrator Functions Software

The design of the error reporting website will involve working with DPS to decide what information will need to be collected when an error occurs. This will include information such as what steps led to the error, what time the error occurred, etc.. A final version of the website will need to be approved by DPS before it is made available for use online.

10.5 Implementation Process

This project team’s primary implementation activities involved preparing the original unit for installation into the Armory parking lot, preparing customer use instructions, devising a method of supporting the unit once it is installed, and beginning construction of the second slave unit to be added.

To prepare the original unit for installation into the Armory parking lot, a few loose ends needed to be resolved. The first of these consisted of obtaining a full runtime license for

22

the Windows XP Embedded software needed to run the client application. By working with the team’s advisors and contacting representatives from Microsoft Corporation, a runtime license was finally obtained in February of 2006. This allowed the May06-02 team to rebuild the parking meter software application and install a fully functioning version of the software onto the primary client. As well as obtain the runtime license, testing needed to be performed on two of the unit’s internal hardware components: the heating element used to keep the unit functional in cold weather conditions, and the backup power supply used to keep the unit running in the event of a power failure. After several attempts, it was found that the heating element was not operational, and needed to be replaced. Thus, a new heating element was acquired and installed into the unit. Also, tests on the backup power supply found that it was insufficient to support the power needs of the unit. Tests are underway to determine if this part can still be used (in a more limited manner), or if it will need to be replaced entirely.

To ensure that customers know how to use the unit once it has been installed, instructions were written up that gave step-by-step details on how customers may purchase parking time using the various methods offered by the software. These instructions were approved by the team’s advisors and by DPS, and will be placed on a sign near the unit upon its installation into the parking lot.

A preliminary version of the error reporting website has been created using the HTML format, and will be shown to both the team’s advisors and to DPS for approval before being made active online. Testing will be performed to ensure that the website reports information accurately and timely to members of the senior design team and advisors. Any revisions to the website will be deferred to the Dec06-02 team.

Parts have recently been received to begin construction on the second client unit. While most of the internal connections and software installation will be done in conjunction with the Dec06-02 team, the finished construction, installation, and testing of the second client unit will be deferred to just the Dec06-02 team.

10.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 methodology for the primary server/client unit once it has been delivered to the parking division is also discussed. Testing issues identified with the second client unit are also identified.

10.6.1 Testing Methodology

Several forms of testing were and are required before the prototype parking meter unit can be installed for testing in the Armory lot.

23

Pre-field and Field TestingTesting 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. This pre-field testing phase is complete, and the unit is prepared to be mounted semi-permanently for field-testing.

o Field-testing will involve operation of unit in a ‘real-life’ non simulated environment for a specified period of time. The Dec06-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 TestingThe 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 Dec06-02 group members. Tests will be well-documented to ensure timely fixing of any problems to be encountered.

Software TestingThe same software running on the original client unit will also be installed on the second unit, and must be tested to ensure proper operation. The software will be tested against existing implementations to ensure uniform operation between units.

10.6.2 Testing Results

Working with the Dec05-02 team, five major rounds of software testing have been completed to verify the functionality of the application. These testing rounds have each identified bugs with the parking meter software. As of the date of this report, all known bugs within the parking meter software have been fixed. Regression testing was used to verify that the software changes made fixed the bugs in question. There is no bug-free software, however, this team, in conjunction with the Dec05-02, has done everything in its power to ensure that no major bugs exist within the code and that the primary server/client unit is ready for delivery to the parking division.

This team was also responsible for testing various hardware components inside the primary server/client system, including the battery backup supply and physical heating element. During testing, it was found that the original heating element was not

24

operational, and a replacement part has consequently been ordered. It was also found that the battery backup supply that was originally inside the unit was insufficient to meet the power requirements demanded of our system, and a new backup supply must therefore be found and ordered. Upon the replacement and subsequent testing of these parts, the primary unit will be ready for installation into the Armory parking lot.

10.7 Project End Results

As of the date of this report, the primary server/client parking meter system has not yet been delivered to the parking division. However, the May06-02 team feels optimistic that the parking meter system will be delivered by the end of the Spring 2006 semester, as there are only a few minor details left to iron out before the installation may occur. The Dec06-02 team will continue with building the second client unit in the Fall 2006 semester.

11. Estimated Resources and Schedules

This section describes an estimate of the resources required to complete this project. Table 11.1-1, Table 11.1-2, and Table 11.1-3 show the original, revised, and actual projections of team member effort for the following tasks. Table 11.1-3 shows the actual effort invested by each team member. Tasks 6 and 7 are partially omitted as tardiness in the ordering of parts and the acquisition of Windows XP embedded runtime licenses pushed back their full completion.

11.1 Estimated Resources

Task 1 – Project FamiliarizationTask 2 – User Instruction SignTask 3 – Testing of Current UnitTask 4 – Preparation and Installation of UnitTask 5 – Support UnitTask 6 – Build Second Unit

Subtask 6.1 – Ordering PartsSubtask 6.2 – Hardware Assembly of Second UnitSubtask 6.3 – Installation of SoftwareSubtask 6.4 – Testing of Second Unit

Task 7 – Parking Meter Simulation SystemSubtask 7.1 – Ordering PartsSubtask 7.2 – Hardware Assembly of Simulation SystemSubtask 7.3 – Installation of SoftwareSubtask 7.4 – Testing of Simulation System

Task 8 – Documentation and Reporting

25

Table 11.1 - Personnel Effort Requirements (original)Name Task

1Task

2Task

3Task

4Task

5Task 6 Task 7 Task 8 Total

6.1

6.2

6.3 6.4

7.1

7.2

7.3

7.4

Michael Arens 28 0 18 8 24 2 4 26 31 13 4 1 12 83 254Kristi Gavin 27 6 14 7 35 1 0 13 27 9 6 2 21 78 246Mikael Nielsen 31 3 13 0 24 2 4 10 23 10 19 12 15 85 251Ben Quach 34 5 15 7 13 1 5 17 24 10 21 1 12 75 240Nichole Wittry 30 4 16 6 28 2 1 30 21 8 4 1 11 72 234

Total 150 18 76 28 124 8 14 9612

6 50 54 17 71 393 1225

Table 11.2 - Personnel Effort Requirements (revised)Name Task

1Task

2Task

3Task

4Task

5Task 6 Task 7 Task 8 Total

6.1

6.2

6.3 6.4

7.1

7.2

7.3

7.4

Michael Arens 37 0 18 8 24 2 4 26 31 13 4 1 12 83 263Kristi Gavin 48 3 14 7 35 1 0 13 27 9 6 2 21 78 264Mikael Nielsen 45 4 13 0 24 2 4 10 23 10 19 12 15 85 266Ben Quach 41 1 15 7 13 1 5 17 24 10 21 1 12 75 243Nichole Wittry 43 2 16 6 28 2 1 30 21 8 4 1 11 72 245Total 214 10 76 28 124 8 14 96 16 50 54 17 71 393 1281

Table 11.3 - Personnel Effort Requirements (actual)Name Task

1Task

2Task

3Task

4Task

5Task 6 Task 7 Task 8 Total

6.1

6.2

6.3 6.4

7.1

7.2

7.3

7.4

Michael Arens 37 0 33 35 24 2 4 26 0 13 4 0 0 83 261Kristi Gavin 48 3 37 42 35 1 0 13 0 9 6 0 0 78 272Mikael Nielsen 45 4 41 39 24 2 4 10 0 10 19 0 0 85 283Ben Quach 41 1 20 30 13 1 5 17 0 10 21 0 0 75 234Nichole Wittry 43 2 42 38 28 2 1 30 0 8 4 0 0 72 270Total 214 10 173 184 124 8 14 96 0 50 54 0 0 393 1320

26

Tables 11.1-4, Table 11.1-5 and Table 11.1-6 show the original, revised and actual resources required for the project.

Table 11.1-4 - Other Resource Requirements (Original)

Equipment and Other Resources

ItemTeam hours Cost

Motherboard/Processor 1 0 $150.00RAM 1 0 $50.00Storage 1 0 $200.00Motherboard/Processor 2 0 $150.00RAM 2 0 $50.00Storage 2 0 $200.00LCD 0 $75.00Keypad 0 $100.00Misc. Buttons 0 $50.00Printer Controller 0 $120.00Ethernet Switch 0 $57.00UPS Battery Backup Unit 0 $100.00Housing 0 $0.00Project Poster 10 $50.00Total 10 $1,352.00

Table 11.1-5 - Other Resource Requirements (revised)

Equipment and Other Resources

ItemTeam hours Cost

Motherboard/Processor 1 0 $150.00RAM 1 0 $50.00Storage 1 0 $200.00Motherboard/Processor 2 0 $150.00RAM 2 0 $50.00Storage 2 0 $200.00LCD 0 $75.00Keypad 0 $100.00Misc. Buttons 0 $50.00Printer Controller 0 $120.00Ethernet Switch 0 $57.00UPS Battery Backup Unit 0 $100.00XP Embedded Runtime Licenses 0 $200.00Housing 0 $0.00

27

Project Poster 10 $25.00Total 10 $1,527.00

Table 11.1-6 - Other Resource Requirements (actual)

Equipment and Other Resources

ItemTeam hours Cost

Motherboard/Processor 1 0 $150.00RAM 1 0 $50.00Storage 1 0 $200.00Motherboard/Processor 2 0 $150.00RAM 2 0 $50.00Storage 2 0 $200.00LCD 0 $130.00Keypad 0 $100.00Misc. Buttons 0 $50.00Printer Controller 0 $120.00Ethernet Switch 0 $57.00UPS Battery Backup Unit 0 $100.00XP Embedded Runtime Licenses 0 $200.00Housing 0 $0.00Project Poster 10 $25.00Total 10 $1,582.00

28

Table 11.1-7, Table 11.1-8, and Table 11.1-9 give the original, revised, and actual financial resources required for the project. Estimates for labor are also included in the tables. Cost of labor is estimated at $11.00/hour.

Table 11.1-7 - Financial Requirements (Original)Item CostParts and materials $150.00RAM 1 $50.00Storage 1 $200.00Motherboard/Processor 2 $150.00RAM 2 $50.00Storage 2 $200.00LCD $75.00Keypad $100.00Misc. Buttons $50.00Printer Controller $120.00Ethernet Switch $57.00UPS Batter Backup Unit $100.00Housing $0.00Project Poster $50.00ServicesShipping and handling $50.00Binding $30.00Equipments subtotal (per unit) $1,432.00Labor ($11.00 / hour)Michael Arens $2,794.00Kristi Gavin $2,706.00Mikael Nielsen $2,761.00Ben Quach $2,640.00Nichole Wittry $2,574.00Labor subtotal (per unit) $13,475.00TOTAL (with labor per unit) $14,907.00

29

Table 11.1-8 - Financial Requirements (revised)Item CostParts and materials $150.00RAM 1 $50.00Storage 1 $200.00Motherboard/Processor 2 $150.00RAM 2 $50.00Storage 2 $200.00LCD $75.00Keypad $100.00Misc. Buttons $50.00Printer Controller $120.00Ethernet Switch $57.00UPS Batter Backup Unit $100.00XP Embedded Runtime Licenses $200.00Housing $0.00Project Poster $50.00ServicesShipping and handling $50.00Binding $30.00Equipments subtotal (per unit) $1,632.00Labor ($11.00 / hour)Michael Arens $2,266.00Kristi Gavin $2,288.00Mikael Nielsen $2,321.00Ben Quach $2,178.00Nichole Wittry $2,167.00Labor subtotal (per unit) $11,220.00TOTAL (with labor per unit) $12,852.00

30

Table 11.1-9 - Financial Requirements (Actual)Item CostParts and materials $150.00RAM 1 $50.00Storage 1 $200.00Motherboard/Processor 2 $150.00RAM 2 $50.00Storage 2 $200.00LCD $75.00Keypad $100.00Misc. Buttons $50.00Printer Controller $120.00Ethernet Switch $57.00UPS Batter Backup Unit $100.00XP Embedded Runtime Licenses $200.00Housing $0.00Project Poster $50.00ServicesShipping and handling $50.00Binding $30.00Equipments subtotal (per unit) $1,632.00Labor ($11.00 / hour)Michael Arens $2,871.00Kristi Gavin $2,992.00Mikael Nielsen $3,113.00Ben Quach $2,574.00Nichole Wittry $2,970.00Labor subtotal (per unit) $14,520.00TOTAL (with labor per unit) $16,152.00

31

11.2 Schedules

Figure 11.2-1 shows the Gantt chart which illustrates the project schedule and deliverables. The blue lines are the original schedule estimates, the red lines are the revised schedule estimates, and the green lines are the team’s actual final project schedule.

32

12. Project Evaluation

This section describes the project objectives and assesses whether or not, and to what level, they have been met.

Project FamiliarizationThe familiarization phase of this project has been completed and fully met. The project team worked hard during its first semester to become familiar with the requirements of the project and functional details of the software through the team’s efforts executing test cases. This semester required further familiarization with the code and hardware. The project team is now quite familiar with how the project works.

User Instruction SignThe user instruction sign was fairly simple to complete and required that the team find a way to convey the user functionality to users in a fairly short and summarized fashion.

Testing of Current UnitThe testing of the current unit has been completed and the team feels that the unit is well prepared for installation in the Armory parking lot. However, on-site testing has yet to take place with the possibility of software changes to fix bugs, meaning that there is more effort in this task that must take place before the project is finished. The team’s preparation efforts included fixing any software bugs that were found and setting up the unit parameters correctly after reinstalling components such as Windows XP Embedded. This task is approximately 90% complete as installation of the unit is expected before the end of the semester it should be completed.

Preparation and Installation of UnitThe preparation and installation milestone of this project has been partially completed. After completing the creation of a fully licensed image of Windows XP Embedded and securing all hardware inside the unit, it is nearly ready for install. 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. Upon the completion of the image installation and the securing of the hardware, the unit will be ready and this milestone will be met, currently it is approximately 90% complete.

Support UnitAlthough the opportunity to fully support the unit on-site has not arisen, efforts have been made to create a system to contact team members and have any errors fixed in a short time. A rough version of an error reporting website has been created and forms to describe the actual incident leading to the error have been created. As it currently stands, this milestone is about 25% complete and much of the remainder of it should be completed by the end of the semester.

33

Build Second UnitBuilding of the second unit has been partially completed. After many delays, the team received parts early this semester for which an order was placed early in the previous semester. As the Windows XP Embedded licensing issue has put off the installation of the original unit, the complete assembly of the second unit has not taken the priority originally expected. However, assembly of the parts has begun and the mechanical engineers assigned to our team have been approached about building housing for it. This milestone is about 25% complete and the remainder of it will fall mostly on the Dec06-02 team.

Parking Meter Simulation SystemParking meter simulation system has been partially completed. Parts for the simulation system were ordered at the same time as parts for the second unit and were received at the same time causing some slight delays. However, assembly of the simulation system has begun and is about 20% complete. Again like the second unit the completion of this milestone will fall mostly on the Dec06-02 team.

Documentation and ReportingDocumentation and reporting of the project has been proceeding at a very fast pace as delays with parts and Windows XP Embedded licenses have given the team ample time to work on it. Work on the reediting of the software functional description has begun and soft copies of documents that were originally hand written have been created. This milestone is approximately 50% complete with more work expected in the remaining weeks of the semester. Hard copies of all necessary documents should be completed by the end of the semester.

Overall EvaluationWith the criteria of “great success”, “success”, and “not a success,” the team has dubbed this project a “success”. The team has not completely reached all of our milestones, but the team has made progress and has mostly met its objectives, with expected further progress yet this semester. Whether the team gets further in the completion of the second unit is dependant on the amount of support needed once the original unit is installed in the Armory parking lot. Difficulties caused by the Windows XP Embedded licensing 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.

34

13. Commercialization

Factors affecting the commercialization and mass production of the parking meter are: Cost of the product Retail price of the product Potential market for the product

The potential market for this product would include large universities like Iowa State as well as large cities with parking problems. This product would cut back on the cost of large parking structures and prevent the need for a large number of parking employees.

14. Recommendations for Additional Work

Future prototype parking meter teams will still be needed to implement the following:

Continued ImplementationFuture prototype parking meter teams will have a few more activities to accomplish. They must provide continuing and effective support of the new parking meter system once it is installed in the Armory parking lot. They must also continue to build a second parking meter slave unit, and develop a simulation system capable of debugging and solving problems from the parking meter lab. Lastly, a major activity will be to develop a method of loading software fixes and changes to the parking meter system by linking a laptop to the parking meter units.

CommercializationThis product is designed for the ISU Parking Division, but upon its successful onsite testing could be much more widely used. Upon the successful completion of the second unit and proof of the networkability of the units, it would be easy to mass produce these units and commercialize them to other Universities, city and state governments, and commercial parking companies.

15. Lessons Learned

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

What Went WellDespite the schedule delays, the team was able to work hard to get most of the deliverables completed on time. Every member took the lead to get certain tasks done, and contributed equally to the project.

35

What Did Not Go WellThere were a few things in this project that did not go well. The major issue the team encountered was the delay experienced in obtaining the necessary XP Embedded runtime license. In order to keep the parking meter unit running for more than 90 days at a time, the application required the full runtime license. The retail price of the runtime license was more than what the project could budget, so a significant amount of time was spent in an effort to obtain the license at a reduced cost. Once the runtime license was procured, the team was able to move forward with the project.

Knowledge GainedThe experience the team gained from this project contained elements of both technical and non-technical knowledge. In the area of technical knowledge, the team gained a better understanding of the software requirements and implementing them, as well as experience using Microsoft Project, Microsoft Visual Studio .NET, Windows XP Embedded, Linux, C++, and MySQL. Also, a wealth of testing knowledge was gained. All of these are important in a real world corporate environment. Non-technical knowledge obtained included time management, working in a team environment, designing a poster, writing technical documents, working with a system that is pre-existing, and reading documentation from other teams.

Things To ChangeIn hindsight, the previous teams should have realized that the system would need a full runtime license, and attempted earlier in the process to obtain one in order to minimize the schedule delays that we experienced. Also, previous teams’ documentation was found to be incomplete or non-existent. Stricter guidelines should have been implemented to ensure the proper documentation is created for future teams and users.

16. Risk Management

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

16.1 Anticipated Risks

The team identified a number of potential risks listed below:

Loss Of Team MemberThe team planned for potentially losing a team member by communicating well with one another and making certain everyone was well involved. The team usually assigned multiple team members to each task to make sure there was not a knowledge imbalance on the team. The team also has used its members’

36

notebooks to write down notes that could be recovered in the case that a team member was lost. In addition, all documentation and source code was stored in a location accessible to all team members.

Hardware FailureTo plan for the risk of hardware failure, the team has had the list of parts close at hand to quickly order new hardware and made sure that all members were informed of any hardware changes.

Parts Procurement DelaysThe 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 LossData 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.

16.2 Anticipated Risks Encountered

Certain risks that were anticipated were in fact encountered in the project.

Parts Procurement DelaysDue to miscommunications regarding parts order forms, and how large the order was, the team encountered a delay in getting the hardware it had ordered. The team’s risk management plan was successful in this, however, because the team did not face a loss of project time as an effect of this delay.

Hardware FailureOne problem the team encountered was a broken connector on the LCD unit. Looking closely at the product details allowed the team to see how it could be fixed, and the team forwarded that responsibility to the proper expertise quickly. Also, 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. Another hardware issue that the team faced was a malfunctioning heating element that needed to be replaced. The UPS power supply was also found to provide insufficient power to the intended hardware components.

16.3 Unanticipated Risks Encountered

This project faced one unanticipated risk that greatly affected the progress of the project.

37

16.3.1 Windows XP Embedded Licensing

The major issue the team encountered was the delay experienced in obtaining the necessary XP Embedded runtime license. In order to keep the parking meter unit running for more than 90 days at a time, the application required the full runtime license. The retail price of the runtime license was more than what the project could budget, so a significant amount of time was spent in an effort to obtain the license at a reduced cost. Once the runtime license was procured, the team was able to move forward with the project.

16.4 Resultant Changes

Due to the unanticipated risk the team encountered, the team has made changes to its management of risks. The team has since carefully reviewed many of the processes that will make the parking meter system work, such as the installation of all components and software to make sure there are no other latent issues that the team is unaware of because of miscommunication between project teams. This has been successful in working out issues with building and installing the final parking meter software.

17. Project Team Information

This section includes information about the client, faculty advisors and student team members of this project.

Client

Doug HoughtonCaptainDepartment of Public Safety31 Armory BuildingAmes, IA 50011Vox: 515-294-1987Fax: 515-294-0383dad@iastate.edu

Faculty Advisors

Dr. John Lamont Professor Ralph Patterson III324 Town Engineering 326 Town EngineeringIowa State University Iowa State UniversityAmes, IA 50010 Ames, IA 50010Vox: 515-294-3600 Vox: 515-294-2428jwlamont@iastate.edu repiii@iastate.edu

Team Members

38

Michael Arens Kristi GavinComputer Engineering Computer Engineering217 Ash Avenue. 216 S. Kellog Apt. 3Ames, IA 50013 Ames, IA 50014515-450-1980 515-231-3260msarens@iastate.edu kgavin@iastate.edu

Mikael Nielsen Ben QuachComputer Engineering Electrical Engineering200 Stanton Apt. 206 1301 Johnson St.Ames, IA 50014 Ames, IA 50010319-361-9196 630-806-1480mikaeln@iastate.edu bquach@iastate.edu

Nichole WittryElectrical Engineering4501 Stienbeck St. #4Ames, IA 50014515-451-1194nwittry@iastate.edu

18. Closing Summary

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

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

19. References

39

Prototype Parking Meter – Phase 4 Project Plan – Dec05-02March 6, 2005From: http://seniord.ece.iastate.edu/dec0502/plan/project_plan.pdf

Prototype Parking Meter – Phase 3 Project Plan – May05-02September 30, 2004From: http://seniord.ee.iastate.edu/may0502/ProjectPlan.pdf

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

Prototype Parking Meter – Phase 4 Final Report – Dec05-02December 14, 2005From: http://seniord.ece.iastate.edu/dec0502/bound%20final%20report.doc

40