Prototype Parking Meter System Phase 3

Transcription

1 Prototype Parking Meter System Phase 3 Status Report Team Code : May05-02 Client : Doug Houghton Captain Department of Public Safety Iowa State University Advisors : Prof. John Lamont, EE/CprE Prof. Ralph Patterson III, EE/CprE Team Members : Chris Dasch, CprE Jesse Pink, EE Peter Stoltenow, CprE Kwan Sin Wing Ted, CprE REPORT DISCLAIMER NOTICE DISCLAIMER: This document was developed as a part of the requirements of an electrical and computer engineering course at Iowa State University, Ames, Iowa. This document does not constitute a professional engineering design or a professional land surveying document. Although the information is intended to be accurate, the associated students, faculty, and Iowa State University make no claims, promises, or guarantees about the accuracy, completeness, quality, or adequacy of the information. The user of this document shall ensure that any such use does not violate any laws with regard to professional licensing and certification requirements. This use includes any work resulting from this student-prepared document that is required to be under the responsible charge of a licensed engineer or surveyor. This document is copyrighted by the students who produced this document and the associated faculty advisors. No part may be reproduced without the written permission of the senior design course coordinator. Submission Date : 15 December 2004

2 Table of Contents List of Figures ii List of Tables iii List of symbols and definitions iv 1. Executive Summary 1 2. Acknowledgement 2 3. Problem Statement General Problem Statement General Solution Approach 2 4. Operating Environment 3 5. Intended Users 3 6. Intended Uses 4 7. Assumptions 4 8. Limitations 4 9. Expected End Result and Other Deliverables Previous Accomplishments Present Accomplishments Required Future Activities Current Project and End-Product Status Recommendation for Continued Effort Documentation of Current Efforts and Results Implementation Activities Testing and Modification Activities Estimated Resources and Schedule Lessons Learned Risk and Risk Management Project team information Closing Summary References 20 Appendix A Parking Enforcement Officer Evaluation Form 21 Appendix B Patron Evaluation Form 22 Appendix C Administrator and Supervisor Flowcharts 23 Appendix D Software Project Headers 57 i

3 List of Figures Figure 1 Parking Lot Sign 5 Figure 2 Gantt Chart, Project deliverables 15 Figure 3 Gantt Chart, Project tasks and subtasks 16 ii

4 List of Tables Table 1 Personnel Effort Requirements (revised) 12 Table 2 Other Resource Requirements 12 Table 3 Financial Requirements 13 iii

5 List of symbols and definitions A Assembly language A low-level computer language that consists of mnemonic codes and symbolic addresses corresponding to machine-language instructions B C D C A high-level object-oriented programming language Dec04-02 The senior design group responsible for the second phase of the project DPS Department of Public Safety, the division of Iowa State University responsible for monitoring parking on the campus E F G H J K L LCD Liquid crystal display, a low-power digital display that uses liquid crystal cells that change reflectivity in an applied electronic field Linux An open source operating system based on UNIX traditionally used for servers. M May04-02 The senior design group responsible for the first phase of the project Motherboard For this project, it is a main circuit board of the embedded computer through which all signals are directed. MySQL MySQL is a fast-relational database manager. A database manager enables adding, retrieving, and processing information stored in a database. The relational aspect of MySQL means that data is stored in separate tables rather than one large table. Relations between each table can be established and information can be retrieved using structured query language (SQL). N O P Q iv

6 R S RAM Random-access memory, the primary working memory in a computer used for the temporary storage of programs and data and in which the data can be accessed directly and modified SQL A standardized language that approximates the structure of natural English for obtaining information from databases T U USB Universal serial bus, a plug-and-play interface between a computer and peripheral devices, such as printers, modems, and keyboards V W Window XP Embedded A compact and modular operating system provided by Microsoft Corporation that allows users to select the exact features and functionality of the OS required for the application or device. X Y Z Wired Ethernet A trademark for a system for exchanging messages between computers on a local area network using wired coaxial, fiber optic or twisted-pair cables v

7 1. Executive Summary There are a number of reasons that a new parking meter system is needed. Currently, the university is planning a number of new parking lots and the current parking meter systems are too expensive to maintain, not configurable enough, and don t allow for communications between individual units within the same lot. This project will address all three of these issues. Currently, the system is relatively inexpensive to manufacture, coming in at around $1,500. If you include man-hours, the system will cost only $15,000. The top of the line systems on the market out there weigh in at over $75,000 and do not have all the planned features that this project will implement. Even with a commercial market mark-up of 400%, the system will still be less expensive than other products. Configuration considerations were also a major reason for beginning this project. Systems that are currently available on the market today do not have the necessary options to facilitate all the different dates (holidays, breaks, etc.) and rate schedules that this project plans to implement. On top of this, there are a number of other options that are also going to be implemented. Finally, the need for individual units to communicate, even though they may be at opposite ends of a parking lot or on different levels of a parking ramp, is paramount. The system will allow for customers to add time to their current stall from any base unit at that lot, regardless of where they first put their money in or where their car is parked in that lot. This will also help parking lot supervisors/attendants to easily manage the lot and find cars that are parked in violation. The system will accomplish many of the aforementioned features by implementing a client-server parking scheme. Throughout a lot a number of client units will allow customers and administrators/supervisors to perform various tasks, such as paying for and adding time to a stall (for customers) to updating rate schedules, adjusting how many stalls are available in a particular lot, checking for parking violations (for supervisors/administrators) and many others. These clients will communicate with a centralized server that can either be located in a physically different location as the client units (such as in a building) or in an enclosure with one of the client units (along with the LCD, coin accepter, printer, etc.) This server will store all the relevant data for a particular parking lot all of the stall information (paid, unpaid, expirations, etc.), the rate structure, and any statistics that may be required. As of this writing, the software required to run the system is approximately 75% complete, and the hardware has all arrived except for one of the cases for a client computer. This leaves the rest of the programming and final integration between the client and the server, as well as connecting all of the components together and 1

8 ensuring operability of the entire system. Finally, an extensive testing process will begin in only a few weeks that will run through the end of the semester. During and after testing, extensive documentation will be created to facilitate administrators and supervisors of the system in maintenance and operation of the 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 and May04-02, Dec04-02 electrical / computer engineering senior design teams. The group 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 Below is our General Problem Statement and Approach. 3.1 General Problem Statement Availability of parking on or near campus has become a concern at Iowa State University. Because of this, several pay-for-parking lots have been installed on the Iowa State campus. With traditional parking meters, such as those seen throughout cities along downtown roads (among other places), one is needed for every parking spot. The lots the group are designing the system for uses centralized units that are able to accept money and track multiple spaces from one or more locations. This setup provides advantages over the traditional parking meters, such as monitoring the entire lot and collecting money from fewer 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 they have already paid for, they must return to the same exact machine. Finally, the lack of communication means that if one unit is disabled, all the data stored in it is lost. Another problem is the current system s 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 a specialist be flown in from a remote location do this, a process that is both expensive and time consuming. 3.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 2

9 implemented on the Iowa State University campus, and in many ways improve on it. The new system will be more affordable and user-friendly, as well as easier to maintain. The solution in development will be implemented with many units all of which will communicate with a central server. All units will be able to communicate using a client/server solution, and users of the lot will be able to add time from any machine located at that lot. The new system will allow DPS parking enforcement officers to receive a printout 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 customers parking in the lots to use the system as well as allowing DPS to easily 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. 4. Operating Environment The unit will be installed in an outdoor location on the campus of Iowa State University in Ames, IA. It must be able to withstand all the weather conditions present in this location. The unit will be able to deal with both extremes of temperatures, as well as all forms of precipitation such as rain, snow, and hail. The unit will be used on a regular basis, often by users that may treat the unit roughly. Because of this, the unit must be durable and designed to withstand extended users. Finally, because the unit will be located on a college campus, it must be sturdy, and resistant to attempts at vandalism. 5. 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 State Campus. The second class of users is DPS parking enforcement officers. They will need additional functionality in order to monitor the parking lots. The third class of user is the administrator. This user will have access to all the features available to the supervisor class, in addition to the ability to change settings of the system, such as the rates and schedules. 3

10 6. Intended Uses The system will have three classes of users (see Section 5), each of which has 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, customers that park in the lot, the system will: o Allow parking spaces to be paid for by a specified amount of time or money 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, parking enforcement/supervisors, 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 administrators of the system will: o Allow users to change hourly rates o Allow users to set holidays o Allow users to add and delete second class users 7. Assumptions Below is a list of all the assumptions that the group are taking into account when designing the system. The lot size will be no more the 1000 spaces The units will not provide change AC power will be provided to the unit The units will only except nickels, dimes, and quarters as payment Iowa State University Facilities Department will install the system 8. Limitations The system has a few functional requirements that must be taken into account when implementing the system. Below lists a few of the limitations that either the group set or that our customer had. The time to have the prototype completed is very limited 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, holidays, and break schedules 4

11 The hardware unit must print receipt upon request The server unit must consist of two redundant processors The server unit must have redundant storage 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 from any client unit in a lot The hardware must provide the current payment status of the lot for parking enforcement 9. Expected End Result and Other Deliverables The end products for this project will be a fully functional master/slave, multi-space parking meter system, complete user documentation, and a detailed technical specification. These items are detailed below: Multi-space parking meter system This system will consist of one of more slave computers connected to a central master computer. The system will be capable of handling up to 1000 parking spaces. The master unit will store all of the parking lot information. The slave 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. Figure 1 Parking lot sign User Manual The user manual will be a document detailing the operation of all the machines in a non-technical way so that any user of the system will be able to understand it. The operations described in the manual will include monitoring occupancy, making rate changes, as well as other enforcement functions. The final draft of the manual will be delivered no later than April of 2005 with a preliminary draft with the rest of the system in December of Technical Specification The technical specification document will be a document describing the technical specifications of both the hardware and software running on the master and slave units. This document is not designed for common users, but instead is 5

12 intended as a resource for future developers and maintainers of the system. The completed technical specification of the system will be delivered with the rest of the system in December Previous Accomplishments Below is our list of accomplishments with the project so far. Fall Spring 2004 In this timeframe we accomplished: Created complete problems definition which containing uses, assumptions, limitations, functional requirements, management procedures, and success evaluation criteria. This part is completely done and state on the project plan. Research hardware and software to meet the project functional requirements, robustness, has current availability and is within budget. All components have been selected within budget but some of the selected components have been changed in phase 2. Spring 2004 Fall 2004 In this timeframe we accomplished: Selected hardware and software for the project implementation. All components are collected and ready to build the prototype. Completed project design with no design issue during implementation. The design is well completed and stated on the project plan. Define functioning product that meet the design requirement, specification and client needs. 11. Present Accomplishments We ve completed the following this semester: Completed user interface flowcharts Completed installation of Windows XP Embedded to the storage device Completed the classes and functions descriptions Implemented classes 12. Required Future Activities The following are important activities: Highest priority: Complete the function implementation Test the main function implementation Complete the hardware implementation 6

13 Done by delivery: Integrate the hardware and software as a prototype for testing. Include master and slave component Testing for the prototype Next semester s activities: On-site testing Research efficiency and user friendliness Bug analysis and removal 13. Current Project and End-Product Status The following is where we currently are as of early November. Master Component o Hardware is completely assembled o Debian Linux is installed o MySQL server is installed o Server database is under development by Dec04 team Slave Component o Hardware Motherboard, CPU, RAM, Solid-State Hard Disk connected Chassis not yet arrived Coin acceptor not yet powered or connected Liquid crystal display not yet powered or connected Printer not yet powered or connected o Software Main function written, but untested Classes written and tested Utility functions under development User input functions developed and tested System Chassis o Not yet modified to hold new components o Base installed at prototype testing location near Armory on Iowa State University campus 14. Recommendation for Continued Effort At this point in the project, the group recommends that development continue as originally envisioned while leaving the option for future expansion. In order to stay within time constraints, some non-critical features may need to be postponed. For 7

14 instance, a future improvement upon the system for another group could be to implement a magnetic stripe card feature, for use with ISUcards. 15. Documentation of Current Efforts and Results This section of the Status Report details the group s current efforts and the results of such efforts. Project Definition Activities The project was already well defined prior to and no significant changes have been made in the current school session. Research Activities No significant research was conducted on this project this semester. Design Activities Flowcharts The current session has largely been spent devising a low-level design for the multi-space parking meter system, which was already defined and high-level designed by previous teams. First, user interface flowcharts were developed from the Software Functional Description, using Microsoft Visio. The flowcharts provide a step-by-step decision-making and functional description of the system. These are included in Appendix C. 8

15 Header Files The second round of the design was to create a list of function descriptions that would be necessary to implement the system in the form of C++ header files. The list was developed using the functional descriptions in both the software functional description and the flowcharts from the previous activity. Each function and class were described in syntactical detail so that their implementation could be completed using only the header files as reference. Included files: Classes o DateTimeType.h class header for date/time data type o RateType.h class header for rate data type that holds rate information for a single rate period o DayRateType.h class header for dayrate data type that holds rate information for an entire day o StateType.h class header for state data type, which holds information for each state in the finite state machine, including an ID number, LCD display text, and next state information o StateCollectionType.h class header for a dynamic data structure of StateType objects User Interface o Admin.h functions that handle complicated user interactions for an administrator user (for states that do more than determine the next state) o Supervisor.h functions that handle complicated user interactions for an supervisor user (for states that do more than determine the next state) o Customer.h functions that handle complicated user interactions for an a customer user (for states that do more than determine the next state) o User.h functions that take complicated user input, such as a date, time, dollar amount, stall number, or range of these /Output o Coins.h handles functions for interfacing with the coin acceptor unit o Keypad.h handles any necessary interpretation or translation of input from the keypad o LCD.h handles interface with the liquid crystal display o Printing.h handles interface with the thermal printer for printing reports and receipts Utility Functions o RateCalc.h functions for calculating cost of a given time period of parking 9

16 o servercomm.h functions for sending and receiving information from the server unit o stateaction.h switch function for calling functions from User Interface section above Main Function parkingmeter.cpp main function including state machine code and global variables These files are included in Appendix D. 10

17 16. Implementation Activities Implementation of the functions described in the header files is well underway. Each of the sets of functions have been developed independently, and later integrated by the team leader. The status of each is as follows: Classes o DateTimeType.cpp complete and tested o RateType.cpp complete and tested o DayRateType.cpp complete and tested o StateType.cpp complete and tested o StateCollectionType.cpp complete and tested includes function to read states from a text file, which has been completed, but not yet tested User Interface o Admin.cpp not yet developed o Supervisor.cpp not yet developed o Customer.cpp currently in development o User.cpp complete and tested /Output o Coins.cpp not yet developed o Keypad.cpp basically complete slight modifications will be necessary to replace standard keyboard input with 16-key pad o LCD.cpp not yet developed o Printing.cpp not yet developed Utility Functions o RateCalc.cpp complete but not yet tested o servercomm.cpp responsibility of Dec04-02 team o stateaction.cpp currently in development Main Function parkingmeter.cpp complete, but modifications may be necessary to make user experience seamless 17. Testing and Modification Activities Unit testing is taking place during the current implementation phase. Classes and utility functions are being developed and tested independently to ensure that they meet the requirements specified in the header files before they are integrated for use with the entire system. System testing will occur after integration of the system is complete, as specified in the project plan. 18. Estimated Resources and Schedule This section will provide an estimate of the resources required for the project and the project schedules. The effort that will be spent on the project has been divided into tasks as listed below. 11

18 Task 1: Project Familiarization Task 2: Low-Level Slave Design Subtask 2.1: User Interface Flowcharts Subtask 2.2: Class and Function Descriptions Subtask 2.3: Block Diagram Task 3: Slave Implementation and Unit Testing Subtask 3.1: Class Implementation Subtask 3.2: Function Implementation Subtask 3.3: Main Function Implementation Subtask 3.4: Hardware Implementation Task 4: System Integration and Testing Task 5: On-Site Testing Task 6: Bug Analysis and Removal Task 7: Demonstration Task 8: Documentation, Literature Table 1 Personnel Effort Requirements (revised) Personal Effort (in hours) Name Task 2 Task 3 Total Task Task 4 Task 5 Task 6 Task 7 Task 8 Christopher Dasch Ted Kwan Jesse Pink Pete Stoltenow Subtotal Hours Total Hours Table 2 Other Resource Requirements Equipment and Other Resources Item Team Hours Cost Motherboard/Processor 1 0 $ RAM 1 0 $50.00 Storage 1 0 $ Motherboard/Processor 2 0 $ RAM 2 0 $50.00 Storage 2 0 $ LCD 0 $75.00 Keypad 0 $ Misc. Buttons 0 $50.00 Printer Controller 0 $ Ethernet Switch 0 $57.00 UPS Battery Backup Unit 0 $ Housing 0 $0.00 Project Poster 10 $50.00 TOTAL 10 $1,

19 Table 3 -- Financial Requirements Item Cost Parts and materials $ Motherboard/Processor 1 $50.00 RAM 1 $ Storage 1 $ Motherboard/Processor 2 $50.00 RAM 2 $ Storage 2 $75.00 LCD $ Keypad $50.00 Misc. Buttons $ Printer Interface $57.00 Ethernet Switch $ UPS Battery Backup Unit $ Housing $0.00 Project Poster $50.00 Services Shipping and handling $50.00 Binding $30.00 Equipment subtotal $1, Labor ($10.75 / hour) Christopher Dasch $2, Ted Kwan $1, Jesse Pink $1, Pete Stoltenow $1, Previous Group Labor $10, (estimate) Labor subtotal $17, TOTAL (With Labor) $19, Schedule Since May05-02 team has inherited this project from two previous teams, the schedule for this team starts in the later design phase. Some of the project deliverables will therefore be delivered in mid-implementation, though they may need to completed at an accelerated pace. 13

20 Included below is a Gantt chart describing the expected project schedule over the next two semesters, with a complete prototype built and tested by the end of the first semester. 14

21 Figure 2 -- Gantt chart, Project deliverables 15

22 Figure 3 -- Gantt chart, Project tasks and subtasks 16

23 19. Lessons Learned Successes Challenges The project group learned how to successfully implement another team s design, and how to integrate our own design with theirs. The group also learned once completed, the project requirements and design should remain static. To attempt to change either one would push the project time table back, and the project would never be completed. Communication between project groups and members was a reoccurring problem. One group or member would have information that another one would need, and that information would not be shared. The group needs to make ourselves available at all times to other members, and respond to requests for information quickly. Technical Knowledge gained Due to this project, the group has successfully learned several pieces of software. These include Microsoft Project, Microsoft Visio, Microsoft Visual Studio.NET, Microsoft Windows XP Embedded and mysql. Non-technical Knowledge gained The project group has learned about the importance of documentation on any project. Without proper documentation from the previous group, the group would not have gotten far. Also learned was the importance of attending project meetings. Meetings are not of much use if all members are not in attendance. Possible changes if done again If the project design could be done over again, the group would make a few changes. First of all more attention should have been paid to the previous team s (Dec0402) documentation. Often the group would have questions about the project that had already been answered in writing. Also, our project group is in the unique situation of designing and implementing our project in one semester, in order to combine our work with the other group. The group has learned that integration takes more time than one would have thought, and the group should schedule appropriately. 17

24 20. Risk and Risk Management A number of potential risks have been identified: Code integration All code implementation will divide into several parts for each member. Even though the group will have a plan to go by, it is possible that compatibility problems may occur when putting the code together due to different format and variables. Moreover, different writing style may lower the code readability and affect the correction time. Deciding on the variables and styles that the group will be using ahead of time (before actually writing any code) will mitigate this risk. Also, any additional function or information must be reported to every member. Equipment damage Unintended damage to project hardware components will take a toll in both time and replacements costs. Properly handling and storing all equipment will mitigate this risk. Equipment Availability Essential hardware may not be available for some unforeseen reason. Many of the items used are produced in low volume and are not always readily available. This risk will be mitigated by thoroughly researching hardware selections. The hardware that has been chosen will most likely provide the type of requirements that the group need. 18

25 21. Project team information The following is all the contact information for the client, faculty advisors, and the team members working on the project. Client Faculty Advisors Doug Houghton Captain Department of Public Safety 31 Armory Building Ames, IA Vox: 515/ Fax: 515/ Dr. John Lamont 324 Town Engineering Iowa State University Ames, IA Vox: 515/ Fax: 515/ Team Members Professor Ralph Patterson III 326 Town Engineering Iowa State University Ames, IA Vox: 515/ Fax: 515/ Chris Dasch 218 S Walnut No 5 Ames, IA / nasch99@iastate.edu Jesse Pink 311 Ash Ave Ames, IA jlink7@iastate.edu Peter Stoltenow 4226 Frederiksen Court Ames, IA / pas@iastate.edu Kwan Sin Wing Ted 1300 Gateway Hills #311 Ames, IA / kwanted@iastate.edu 19

26 22. Closing Summary Parking has become a growing problem with more and more automobiles on the road. In densely populated areas such as urban centers and corporate and academic campuses, the problem is only worse. As Iowa State works to cope with its parking predicament, it also needs a cost-effective solution to finance the construction and maintenance of new lots. Current multi-space pay-for-parking systems are too expensive and rigid to meet the university s needs, and old-style individual parking meters are not practical for large lots. The design outlined in this document will allow for a system that can handle large parking areas, while at the same time being inexpensive enough to be used widely across campus and flexible enough to allow for diverse parking situations, and create a large source of revenue for Iowa State University. 23. References Prototype Parking Metering System Phase 2: Design Document. Dec 04-02, 6 April Software Functional Description. Dec 04-02, J. Lamont & R. Patterson III, 19 July

27 Appendix A Parking Enforcement Officer Evaluation Form Tester Name: Date Completed: Tester Phone #: Tester Address: Instructions: The purpose of this test is to evaluate the use of this system to monitor and enforce parking lot payments. Before completing the survey below, complete the following tasks: 1) Print the list of paid and unpaid stalls for enforcement. 2) Empty the coin box and retrieve the auditing receipt. 3) Print the diagnostics report. Please circle the number that best describes your response as follows: 1 Very Poor 2 Poor 3 Indifferent 4 Good 5 Excellent Were the instructions clear and easy to understand? Was it clear and easy how to print the enforcement receipt? Did the enforcement receipt have all of the information that you needed? If not, please comment on what info was missing Did the auditing receipt print when you opened the unit to empty the coin box? Did the auditing receipt that printed when you opened the coin box have the information that you desired? If not, please comment on what info was missing. Were you easily able to print a diagnostic report? Did the diagnostic report contain all of the information that you thought was needed? Were the key inputs easy to use? Did the instructions clearly indicate which keys you were to press? What is your overall impression of this machine Please provide any additional comments or suggestions on the back of this form 21

28 Appendix B Patron Evaluation Form Tester Name: Date Completed: Tester Phone #: Tester Address: Instructions: The purpose of this test is to evaluate the use of the parking meter. Before completing the survey below, please complete the following tasks: 1) Pay for a parking space by entering coins first and not by choosing the amount of time you would like to pay for. 2) Add time to the parking space by entering the time you would like to pay for and then depositing coins. 3) Complete the above transactions with and without printing a receipt. 5) Attempt to cancel the sale before you insert coins. Please circle the number that best describes your response as follows: 1 Very Poor 2 Poor 3 Indifferent 4 Good 5 Excellent Were the instructions clear and easy to understand? Was it clear and easy how to enter the stall number? Was it clear and easy to enter the coins first and not choose the amount of time for payment? Was it clear and easy to choose the amount of time to pay for and then insert coins? Was it clear and easy to print a receipt? Did the receipt have all of the information that you thought was necessary? If not, please comment on what was missing Were you able to cancel the transaction before depositing coins? Were the key inputs easy to use? Did the instructions clearly indicate which keys you were to press? What is your overall impression of this machine Please provide any additional comments or suggestions on the back of this form 22

29 Appendix C Administrator and Supervisor Flowcharts 7.1 Administrator/Supervisor Login (contd.) A2 Set User globally Administrator Identify User Supervisor A3 S1 23

30 7.2 Administrator Menu A3 Display Administrator Main Menu (Fig 7-2-1) User Display error message (Figure ) 9, Cancel Value? 0, 4-8, Enter, Arrows 1 3 Display Admin Logout (Fig 7-2-2) A10 2 A20 A30 W1 7.3 Supervisor Menu S1 Display Supervisor Main Menu (Fig 7-3-1) User Display error message (Figure ) 0, Enter, L & R Arrows Scroll Up One Line Display Admin Logout (Fig 7-2-2) W1 9, Cancel A10 1 A Value? S70 U Arrow D Arrow S80 Scroll Down One Line A30 S60 S40 S50 24

31 7.4 Stall List A10, A11 A10 A3 S1 Display Unpaid or Paid Parking Lot Print Menu (Fig 7-4-1) Admin User Admin or Super? Super User Display error message (Figure ) 9 Cancel Value? 1 2 0, 3-8, Enter, Arrows Display Admin Logout (Fig 7-2-2) A11 A16 W Unpaid Stall List A11 A3 S1 Display Unpaid Stall Number Menu (Fig 7-4-2) Admin User Admin or Super? Super User Display error message (Figure ) 9 Value? 0, 3-8, Enter, Arrows Cancel 1 2 Display Logout (Fig 7-2-2/3) Query Server for All Unpaid Stall Numbers Display Enter Range (Fig 7-4-6) W1 Print Unpaid Stall- Number List (Fig 7-4-4/5) Display Printing (Fig 7-4-3) Range Valid? Yes Query Server for All Unpaid Stall Numbers in Range No Display error message (Fig 7-4-7) 25

32 7.4-2 Paid Stall List A12 A12 A3 S1 Display Paid Stall Number Menu (Fig 7-4-8) Admin User Admin or Super? Super User Display error message (Figure ) 9 Value? 0, 3-8, Enter, Arrows Cancel 1 2 Display Logout (Fig 7-2-2/3) Query Server for All Unpaid Stall Numbers Display Enter Range (Fig ) W1 Print Paid Stall- Number List (Fig /11) Display Printing (Fig 7-4-9) Range Valid? Yes No Display error message (Fig 7-4-7) Query Server for All Unpaid Stall Numbers in Range 26

33 7.5 Print Total Parking Lot and Individual Stall Statistics A20 A20 A3 S1 Display Statistics Menu (Fig 7-5-1) Admin User Admin or Super? Super User Display error message (Figure ) 9 Value? 0, 5-8, Enter, Arrows Cancel Display Logout (Fig 7-2-2/3) Display Printing (Fig 7-5-2) Display Printing (Fig 7-5-4) Display Printing (Fig 7-5-6) Display Printing (Fig 7-5-8) W1 Print Lot Stats by Time (Fig 7-5-3) Print Lot Stats by Num of Users (Fig 7-5-5) Print Stall Stats by Time (Fig 7-5-7) Print Stall Stats by Time (Fig 7-5-9) 27

34 7.6 Correcting System Malfunctions A30 (functionality not yet designed/planned) A30? 28

35 S40, S41 S40 / Print system parameters menu screen (Fig ) User Display error message (Figure ) 0, 6, 7, 8, ENTER, L, R 9 Value? Up Arrow Scroll Up One Line Cancel 1 5 Down Arrow Scroll Down One Line S Display Admin Logout (Fig 7-3-2) S41 S42 S43 S44 S45 W1 S41 S1 9 / print rate-structure menu screen (Fig ) 0, 5, 6, 7, 8, ENTER, L, R Display error message (Figure ) User Cancel Scroll Up One Line Value? U Display Admin Logout (Fig 7-3-2) 1 4 D Scroll Down One Line 2 3 S41.1 S41.4 W1 S41.2 S

36 S41.1, S41.11, S41.12 S41.1 in-session rate menu screen (Fig ) 0, 6, 7, 8, ENTER, L, R Display error message (Figure ) User S41 9 U Scroll Up One Line Value? D Scroll Down One Line Display Admin Logout (Fig 7-3-2) 1 5 S S41.15 W1 S41.12 S41.14 S41.13 S41.11 S in-session peakrate-value screen (Fig ) in-session shoulder-rate value screen (Fig ) S41.1 S41.1 D, R, U (Fig ) D, R, U (Fig ) 0-9, ENTER, L 0-9, ENTER, L shown in Fig updated. L ENTER signifies end completion of entry ( ) display in shown in Fig updated. L ENTER signifies end completion of entry ( ) display in Update Insession peakrate value in database S41.1 Update Insession shoulder-rate value in database S

37 S41.13 S41.13, S41.14, S41.15 S41.14 S41.1 in-session off-peak rate-value screen (Fig ) S41.1 in-session weekend-rate value screen (Fig ) D, R, U (Fig ) D, R, U (Fig ) 0-9, ENTER, L 0-9, ENTER, L shown in Fig updated. L ENTER signifies end completion of entry ( ) display in shown in Fig updated. L ENTER signifies end completion of entry ( ) display in Update Insession offpeak rate value in database S41.1 Update Insession weekend rate value in database S41.1 S41.15 Display Printing in-session rate list message screen (Fig ) Print In-session Rate values printout (Fig ) S

38 S41.2, S41.21, S41.22 S41.2 / print non-session rate-value menu screen (Fig ) 0, 4, 5, 6, 7, 8, ENTER, L, R Display error message (Figure ) User S41 9 U Scroll Up One Line Value? D Scroll Down One Line Display Admin Logout (Fig 7-3-2) 1 W1 S S41.22 S41.23 S41.21 S41.22 non-session weekday rate screen (Fig ) non-session weekend rate value screen (Fig ) S41.2 S41.2 D, R, U (Fig ) D, R, U (Fig ) 0-9, ENTER, L 0-9, ENTER, L shown in Fig updated. L ENTER signifies end completion of entry ( ) display in shown in Fig updated. L ENTER signifies end completion of entry ( ) display in Update nonsession weekday rate value in database S41.2 Update nonsession weekend rate value in database S

39 S41.23 S41.23, S41.3, S41.31, S41.32 S41.3 Display Printing non-session rate list message screen (Fig ) / print holiday-rate value menu screen (Fig ) Print non-session rate values printout (Fig ) S41 9 User 0, 3, 4, 5, 6, 7, 8, ENTER, L, R U Display error message (Figure ) Scroll Up One Line S41.2 Value? D Scroll Down One Line Display Admin Logout (Fig 7-3-2) 1 2 W1 S41.31 S41.32 S41.31 holiday rate screen (Fig ) S41.32 S41.3 D, R, U (Fig ) Display Printing holiday rate list message screen (Fig ) 0-9, ENTER, L shown in Fig updated. L ENTER signifies end completion of entry ( ) display in Print holiday-rate values printout (Fig ) S41.3 Update holiday rate value in database S

40 S41.4, S41.41, S41.42 S41.4 / print special event rate value menu screen (Fig ) 0, 3, 4, 5, 6, 7, 8, ENTER, L, R Display error message (Figure ) User S41 9 U Scroll Up One Line Value? D Scroll Down One Line Display Admin Logout (Fig 7-3-2) 1 2 W1 S41.41 S41.42 S41.41 special event rate screen (Fig ) S41.42 S41.4 D, R, U (Fig ) Display Printing special event rate list message screen (Fig ) 0-9, ENTER, L shown in Fig updated. L ENTER signifies end completion of entry ( ) display in Print special event rate values printout (Fig ) S41.4 Update special event rate value in database S

41 S42 S42 S40 9 / print rate schedule times menu screen (Fig ) 0, 4, 5, 6, 7, 8, ENTER, L, R Display error message (Figure ) User U Scroll Up One Line 1 3 Display Admin Logout (Fig 7-3-2) 2 D Scroll Down One Line W1 S42.1 S42.2 S

42 S42.1 S42.1, S42.11, S42.12 / print in-session rate-times menu screen (Fig ) 0, 7, 8, ENTER, L, R Display error message (Figure ) User S42 9 U Scroll Up One Line Value? D Scroll Down One Line Display Admin Logout (Fig 7-3-2) W1 1 S S42.16 S42.12 S42.15 S42.13 S42.14 S42.11 S42.12 in-session peak rate-times value screen (Fig ) pre-peak shoulder rate-times value screen (Fig ) S42.1 S , ENTER, L, R, D, U 0-9, ENTER, L, R, D, U shown in Fig updated. L R tabs between time fields. U/D selects AM/PM. ENTER signifies end completion of entry. Update Insession peakrate-times value in database ( ) display in S42.1 shown in Fig updated. L R tabs between time fields. U/D selects AM/PM. ENTER signifies end completion of entry. Update prepeak shoulder rate-times value in database ( ) display in S

43 S42.13 S42.13, S42.14, S42.15, S42.16 S42.14 post-peak shoulder ratetimes value screen (Fig ) off peak rate-times value screen (Fig ) S42.1 S , ENTER, L, R, D, U 0-9, ENTER, L, R, D, U shown in Fig updated. L R tabs between time fields. U/D selects AM/PM. ENTER signifies end completion of entry. Update Insession peakrate-times value in database ( ) display in S42.1 shown in Fig updated. L R tabs between time fields. U/D selects AM/PM. ENTER signifies end completion of entry. Update prepeak shoulder rate-times value in database ( ) display in S42.1 S42.15 S42.1 in-session weekend ratetimes value screen (Fig ) S42.16 Display Printing in-session ratetime list message screen (Fig ) 0-9, ENTER, L, R, D, U shown in Fig updated. L R tabs between time fields. U/D selects AM/PM. ENTER signifies end completion of entry. Update Insession peakrate-times value in database ( ) display in S42.1 Print in-session rate-time values printout (Fig ) S

44 S42.2 S42.2 / print in-session rate-times menu screen (Fig ) 0, 4, 5, 6, 7, 8, ENTER, L, R Display error message (Figure ) User S42 9 U Scroll Up One Line Value? D Scroll Down One Line Display Admin Logout (Fig 7-3-2) S42.21 W1 S42.22 S42.23 S42.21 S42.22 non-session weekday ratetimes value screen (Fig ) non-session weekend ratetimes value screen (Fig ) S42.2 S , ENTER, L, R, D, U 0-9, ENTER, L, R, D, U shown in Fig updated. L R tabs between time fields. U/D selects AM/PM. ENTER signifies end completion of entry. Update nonsession weekday ratetimes value in database ( ) display in S42.2 shown in Fig updated. L R tabs between time fields. U/D selects AM/PM. ENTER signifies end completion of entry. Update nonsession weekend ratetimes value in database ( ) display in S

45 S42.23 S42.23 Display Printing non-session ratetime list message screen (Fig ) Print non-session rate-time values printout (Fig ) S

46 S42.3, S42.31, S42.32 S42.3 / print holiday ratetimes menu screen (Fig ) Display error message (Figure ) User S42 9 0, 3, 4, 5, 6, 7, 8, ENTER, L, R, U, D Value? Display Admin Logout (Fig 7-3-2) W1 1 S S42.32 S42.31 S42.32 holiday rate-times value screen (Fig ) Display Printing holiday rate-time list message screen (Fig ) S , ENTER, L, R, D, U Print holiday ratetime values printout (Fig ) shown in Fig updated. L R tabs between time fields. U/D selects AM/PM. ENTER signifies end completion of entry. Update nonsession weekday ratetimes value in database ( ) display in S42.3 S

47 S43, S43.1 S43 S40 9 / print nonpermanent schedule menu screen (Fig ) 0, 7, 8, ENTER, L, R Display error message (Figure ) User U Scroll Up One Line Display Admin Logout (Fig 7-3-2) D Scroll Down One Line W1 S43.1 S43.2 S43.3 S43.4 S43.5 S43.6 S43.1 S43 9 the calendar-year schedule-menu screen (Fig ) 0, L, R U Display error message (Figure ) Scroll Up One Line Display Admin Logout (Fig 7-3-2) User D Scroll Down One Line W1 S S43.18 S S43.17 S43.13 $43.14 S43.15 S

48 S43.11 S43.11, S43.12, S43.13, S43.14 S43.12 S43.1 the fall semester date values screen (Fig ) S43.1 the Thanksgiving break date values screen (Fig ) 0-9, ENTER, L, R U, D (Fig ) 0-9, ENTER, L, R U, D (Fig ) shown in Fig updated. L R tabs between time fields. ENTER signifies end completion of entry. Update the fall semester date values stored in database ( ) display in S43.1 shown in Fig updated. L R tabs between time fields. ENTER signifies end completion of entry. Update the Thanksgiving break date values stored in database ( ) display in S43.1 S43.13 S43.14 S43.1 the post-fall/prespring semester date values screen (Fig ) 0-9, ENTER, L, R U, D (Fig ) S43.1 the spring semester date values screen (Fig ) 0-9, ENTER, L, R U, D (Fig ) shown in Fig updated. L R tabs between time fields. ENTER signifies end completion of entry. Update the post-fall/prespring semester date values stored in database ( ) display in S43.1 shown in Fig updated. L R tabs between time fields. ENTER signifies end completion of entry. Update the spring semester date values stored in database ( ) display in S

49 S43.15 S43.15, S43.16, S43.17, S43.18 S43.16 S43.1 the spring-break date values screen (Fig ) S43.1 the post-spring/ pre-summer semester date values screen (Fig ) 0-9, ENTER, L, R U, D (Fig ) 0-9, ENTER, L, R U, D (Fig ) shown in Fig updated. L R tabs between time fields. ENTER signifies end completion of entry. S43.17 Update the spring break date values stored in database ( ) display in S43.1 shown in Fig updated. L R tabs between time fields. ENTER signifies end completion of entry. S43.18 Update the post-spring/ pre-summer semester date values stored in database ( ) display in S43.1 S43.1 the summer session date values screen (Fig ) 0-9, ENTER, L, R U, D (Fig ) S43.1 the post-summer/ pre-fall semester break date values screen (Fig ) 0-9, ENTER, L, R U, D (Fig ) shown in Fig updated. L R tabs between time fields. ENTER signifies end completion of entry. Update the summer session date values stored in database ( ) display in S43.1 shown in Fig updated. L R tabs between time fields. ENTER signifies end completion of entry. Update the post-summer/ pre-fall semester break date values stored in database ( ) display in S

50 S43.2, S43.3, S43.38 S43.2 S43.38 Display Printing calendar year schedule list message screen (Fig ) Display Printing permanent holiday schedule list message screen (Fig ) Print non-session rate-time values printout (Fig ) Print permanent holiday schedule printout (Fig ) S43 S43.3 S43.3 S43 9 permanent holiday schedule menu screen (Fig ) 0, L, R U Display error message (Figure ) Scroll Up One Line Display Admin Logout (Fig 7-3-2) User D Scroll Down One Line W1 S S S43.37 S43.33 $43.34 S43.35 S

51 S43.31 S43.31, S43.32, S43.33, S43.34 S43.32 S43.3 New Year s Day date screen (Fig ) S43.3 Martin Luther King s Birthday date screen (Fig ) 0-9, ENTER, L U, D, R (Fig ) 0-9, ENTER, L U, D, R (Fig ) shown in Fig updated. L ENTER signifies end completion of entry. S Update New Year s Day date value stored in database ( ) display in S43.3 shown in Fig updated. L ENTER signifies end completion of entry. S43.34 Update the post-spring/ pre-summer semester date values stored in database ( ) display in S43.3 S43.3 Memorial Day Date screen (Fig ) 0-9, ENTER, L U, D, R (Fig ) S43.3 Independence Day date values screen (Fig ) 0-9, ENTER, L U, D, R (Fig ) shown in Fig updated. L ENTER signifies end completion of entry. Update Memorial Day date value stored in database ( ) display in S43.3 shown in Fig updated. L ENTER signifies end completion of entry. Update Independence Day date value stored in database ( ) display in S