1. Prototype Parking Meter – Phase 5
Project team: May06-02
Client
Iowa State University Parking Division
Advisors
John W. Lamont, Ralph E. Patterson III
Team Members
Michael Arens
Kristi Gavin
Mikael Nielson
Ben Quach
Nichole Wittry

2. Overview
By collaborating with the ISU Parking Division, the objective of this project is to develop a demonstrable, microprocessor-based parking meter unit that is cheaper and more flexible than Iowa State’s current parking meter system.
This presentation will cover the following topics:
Current project status
Goals for next semester
Planned support and problem handling
Second slave unit hardware design
Project concerns

3. Where Are We At?
A functioning prototype unit has been constructed according to previous team’s design
Formal test plan has been written and executed
Waiting for XPe license before installing in Armory parking lot

4. Accomplishments for Fall 2005
Performed spot-check testing to verify key functionalities
Verified the server back-up functionality.
Resolved code problems and hardware issues.
Wrote user instructions to be read by the customers using the system.
Ordered parts for the second slave unit.

5. Goals for Next Semester
Last minute checks to perform on prototype unit:
Review Software Tests
Review tests that showed bugs
Test other important functionality
Review Hardware Tests
Servers
Heater
Printer
Coin Accepter
Battery Backup
Check Connections
LCD
Keypad
Disk on Chip
Power
Check Safety Hazards
Fix Server Power Supply grounding issues
Check that all cords are out of the way

6. Goals for Next Semester
Build second slave unit
Assembly documentation provided by previous teams
Continue document development
Quick Start Guide
Update Software Functional Description
DPS User’s Manual
Cookbook – unit build information

7. Supporting the System: Expected Failures
Potential Physical Failures
Heater breaks
Printer errors
LCD disconnection
Keypad issues
Coin acceptor controller card breaks
Power failure
Server electrical problems
Once the prototype unit has been installed in the Armory parking lot, our team will also be responsible for providing support and maintenance of the system. Although we have performed numerous tests to verify the system functionalities, we recognize that there are several areas where a failure could occur. Some of the potential physical failures we can expect include…

8. Supporting the System: Expected Failures
Potential Software Issues
Printer sharing
Coin acceptor data collection
Hidden bugs
Interaction between units
Other Issues
User error
Some of the software failures we expect include…
Other potential issues include user error, which could occur if either administrators or customers fail to understand how to use the system.

9. Supporting the System: How the Team will be Notified
DPS phone number located on sign for
students to call
Online feedback form for DPS to contact
senior design team
Should a failure actually occur with the system, a number will be posted on the instruction sign that students can call to notify DPS. If a DPS officer discovers the problem, or is notified of the problem by a student, an online feedback form will be in place that DPS can use to notify the senior design team. A preliminary version of this webpage has been created, though we are planning to gather feedback from advisors and client Doug Houghton regarding any improvements that may be made. As you can see, the form asks a few specific questions, then provides space for users to add more specific details about the problem. Once the form is submitted, an will be sent to the senior design team, who will handle the problem according to the methods to be described.

10. Supporting the System: How the Team will be Notified
Website example screenshot

11. Supporting the System: How the Team will be Notified
Website example screenshot

12. Supporting the System: Who Will Resolve the Issue
A weekly chart will dictate who is initially responsible for attempting to resolve the issue. Should this person need further assistance, other team members may be contacted.
Person A
Person B
Person C
Person D …
Person n
Week 1: X
Week 2:
Week n:
To provide continuous support for the system, a weekly chart will be constructed, dictating who is initially responsible for resolving the issue. Should this person need further assistance, they are free to contact other members of the team for help.
After December 2006, continued support will be contingent upon the creation of a December 2006 team.

13. Initial Problem Analysis Flowchart
Restart the Parking Meter system. Does the system turn on and display respond? No
Is the machine on and the display screen still responding?
Yes
Is there sufficient information to reproduce the problem? No
Yes
Yes No
Run a few test cases and document the problem. Keep a lookout for possible causes of problem in future.
Run tests based on the information provided to attempt to pinpoint the issue. Keep a record of what was tried and look out for the problem in the future.
Open the meter and look around for loose cable or damage. Is there any obvious problem?
Reproduce the problem and narrow down the cause and fix. No
Further analysis is needed by team.
After our team has received a problem report from DPS, the team will then proceed to analyze the issue using this flowchart. First we ask ourselves: Is the machine on and the display screen still responding? If its not, our first step will be to restart the parking meter system and see if it turns on an responds after a reboot. If that solves the issue, we will continue to run a few test cases to ensure that the meter is functioning again, and then we will document the problem and keep on the lookout for possible causes of the freeze up. If the meter does not turn back on, the next step will be to open up the meter itself and look around for loose cables or obvious damage. Hopefully we would be able to see what the problem is, but further analysis by the team will be needed for internal connection damage.
Back to the beginning, if the parking meter is still on and responding, our first step will be to make sure we can reproduce the problem that was reported. If we can reproduce the problem, we can narrow down the cause and assign a team to fix the issue. If we cannot reproduce the issue, we will continue to run tests based on the information that has been provided to us in an attempt to pinpoint the issue. We will be sure to keep a record of the problem and what was tried to reproduce it, and we will keep a look out for the same problem in the future.
Of course, right now this is our best estimate of what important steps to analyze problems will be needed. As we become more familiar with the problems we will face and become more efficient, we may revise the flow chart to include more steps or information.
Yes
Attempt to reconnect or correct obvious problems. If this does not solve the issue, further analysis is needed by team.

14. Parking Meter Support Documentation
Documentation Logbook will include
Copy of feedback form
Who worked on problem and when
What did and did not work
What triggered issue
Other comments
New problems and fixes incorporated into Cookbook
Another major part of our parking meter support plan, is the documentation involved. Each problem report will be copied and included into a logbook that will detail who worked on the problem, what the problem was, what did and did not work in the course of fixing the issue, and what the possible triggers of the problem were. There will also be a space for the documenter to make comments that might not fit into any other category.
Lastly, new problems and fixes will be incorporated into our overall “Cookbook” which Mike described earlier. That way, future parking meter teams or support technicians will know what to do when a similar problem arises.

15. Hardware Design This unit is similar to the existing unit
Only contains the hardware for the slave part of the system
Same parts as existing slave for easy replication

16. Hardware Design

17. Hardware Design Via Epia 800 MHz motherboard Contains an integrated
processor, Ethernet, USB,
serial ports
256 MB PC133 RAM $40
512 MB MDI1151-D512
Disk on chip $100

18. Hardware Design StacoSwitch M151XX05 - $90
This unit will use an off the shelf keypad instead of the homemade one in the existing unit.
Standardization and drivers to support
Backlit keys for night visibility
Matrix Orbital LCD 4041 LCD
Module $118
4 lines by 40 character display

19. Hardware Design Two serial devices Coin Acceptor and controller $300
Controller provides serial
data to the motherboard
Thermal printer $350
drivers provided

20. Hardware Design Power supply and case $128
Provides power for the motherboard
SPU IP power supply $69
Provides power for the thermal
printer and Coin-acceptor
APC BK650MC UPS
power backup
Last for 4 hours to run unit
in case of power failure

21. Slave Unit Documentation
Cookbook will include
Slave unit assembly instructions
Problems encountered
Tips for easier assembly
How to create and install Windows XP embedded
How to install drivers for coin acceptor and printer
How to transfer software application to parking meter system
Parts list for easy reordering
During the course of our team working to assemble and test our second parking meter slave unit, we will continue to update and complete our cookbook with important information and instructions.
We will include step-by-step assembly instructions along with problems we encounter along the way, and tips for making the assembly easier. We will also include instructions on how to create and install the windows xp embedded image, how to install the drivers for the coin acceptor and thermal printer, and how to transfer the application software onto the parking meter system. A parts list for the easy re-ordering of parts will also be included in our cookbook, just in case a part gets damaged during assembly, or out in the parking lot itself.

22. Project Concerns XPe run-time license
Ordering/manufacturing of the case
Parts have yet to be ordered for the second slave unit

23. Summary
Parking has become an important challenge lately in urban centers and universities.
An efficient and low-cost meter system will help the University to focus on alleviating the parking problem directly.
Will save time and money
Flexible and architecturally simple.
Future changes to the system can be implemented should the need arise.

24. Questions?