Prototype Parking Meter System – Phase 3 Status...

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

i

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 2 3.1 General Problem Statement 2 3.2 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 5 10. Previous Accomplishments 6 11. Present Accomplishments 6 12. Required Future Activities 6 13. Current Project and End-Product Status 7 14. Recommendation for Continued Effort 7 15. Documentation of Current Efforts and Results 8 16. Implementation Activities 11 17. Testing and Modification Activities 11 18. Estimated Resources and Schedule 11 19. Lessons Learned 17 20. Risk and Risk Management 18 21. Project team information 19 22. Closing Summary 20 23. 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

ii

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

iii

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

iv

List of symbols and definitions A Assembly language

A low-level computer language that consists of mnemonic codes and symbolic addresses corresponding to machine-language instructions

B C C

A high-level object-oriented programming language

D 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

v

R RAM Random-access memory, the primary working memory in a computer used for the temporary storage of programs and data and in which the data can be accessed directly and modified

S 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.

Wired Ethernet A trademark for a system for exchanging messages between computers on a local area network using wired coaxial, fiber optic or twisted-pair cables

X – Y – Z

1

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

2

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

3

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.

4

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

5

Figure 1 – Parking lot sign

• 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.

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 2004.

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

6

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 2004.

10. Previous Accomplishments Below is our list of accomplishments with the project so far. Fall 2003 - 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

7

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

8

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

Flowcharts 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.

9

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 UserInput.h – functions that take complicated user input, such as a date, time, dollar amount, stall number, or range of these

• Input/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

10

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.

11

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 UserInput.cpp – complete and tested

• Input/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.

12

• 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)

Task 2 Task 3 Name Task 1 2.1 2.2 2.3 3.1 3.2 3.3 3.4 Task 4 Task 5 Task 6 Task 7 Task 8

Total

Christopher Dasch 10 4 11 9 9 38 35 5 19 17 17 5 8 187 Ted Kwan 8 3 7 7 7 41 27 2 17 17 20 5 12 173 Jesse Pink 18 9 4 6 3 15 30 8 24 18 13 5 37 190 Pete Stoltenow 14 11 7 6 6 30 35 15 20 14 13 5 10 186 Subtotal Hours 50 27 29 28 25 124 127 30 80 66 63 20 67 736 Total Hours 50 84 306 80 66 63 20 67 736

Table 2 – Other Resource Requirements Equipment and Other Resources Item Team Hours Cost Motherboard/Processor 1 0 $150.00 RAM 1 0 $50.00 Storage 1 0 $200.00 Motherboard/Processor 2 0 $150.00 RAM 2 0 $50.00 Storage 2 0 $200.00 LCD 0 $75.00 Keypad 0 $100.00 Misc. Buttons 0 $50.00 Printer Controller 0 $120.00 Ethernet Switch 0 $57.00 UPS Battery Backup Unit 0 $100.00 Housing 0 $0.00 Project Poster 10 $50.00 TOTAL 10 $1,352.00

13

Table 3 -- Financial Requirements Item Cost Parts and materials $150.00 Motherboard/Processor 1 $50.00 RAM 1 $200.00 Storage 1 $150.00 Motherboard/Processor 2 $50.00 RAM 2 $200.00 Storage 2 $75.00 LCD $100.00 Keypad $50.00 Misc. Buttons $120.00 Printer Interface $57.00 Ethernet Switch $100.00 UPS Battery Backup Unit $100.00 Housing $0.00 Project Poster $50.00 Services Shipping and handling $50.00 Binding $30.00 Equipment subtotal $1,532.00 Labor ($10.75 / hour) Christopher Dasch $2,053.25 Ted Kwan $1,892.00 Jesse Pink $1,978.00 Pete Stoltenow $1,988.75 Previous Group Labor $10,000.00 (estimate) Labor subtotal $17,912.00 TOTAL (With Labor) $19,444.00 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.

14

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.

15

Figure 2 -- Gantt chart, Project deliverables

16

Figure 3 -- Gantt chart, Project tasks and subtasks

17

19. Lessons Learned Successes

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.

Challenges

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.

18

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.

19

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 Doug Houghton

Captain Department of Public Safety 31 Armory Building Ames, IA 50011 Vox: 515/294-1987 Fax: 515/294-0383 [email protected]

Faculty Advisors

Dr. John Lamont 324 Town Engineering Iowa State University Ames, IA 50010 Vox: 515/294-3600 Fax: 515/294-6760 [email protected] Professor Ralph Patterson III 326 Town Engineering Iowa State University Ames, IA 50010 Vox: 515/294-2428 Fax: 515/294-6790 [email protected]

Team Members

Chris Dasch 218 S Walnut No 5 Ames, IA 50010 515/233-5189 [email protected] Jesse Pink 311 Ash Ave Ames, IA 50010 [email protected]

Peter Stoltenow 4226 Frederiksen Court Ames, IA 50010 515/572-7860 [email protected] Kwan Sin Wing Ted 1300 Gateway Hills #311 Ames, IA 50014 515/441-0224 [email protected]

20

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 2004 http://seniord.ece.iastate.edu/dec0402/Dec04-02%20Design%20Document.pdf Software Functional Description. – Dec 04-02, J. Lamont & R. Patterson III, 19 July 2004

21

Appendix A Parking Enforcement Officer Evaluation Form

Tester Name:___________________________ Date Completed:_________________ Tester Phone #:__________________ Tester Email 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? 1 2 3 4 5 Was it clear and easy how to print the enforcement receipt? 1 2 3 4 5 Did the enforcement receipt have all of the information that you needed? If not, please comment on what info was missing. 1 2 3 4 5

Did the auditing receipt print when you opened the unit to empty the coin box? 1 2 3 4 5

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.

1 2 3 4 5

Were you easily able to print a diagnostic report? 1 2 3 4 5 Did the diagnostic report contain all of the information that you thought was needed? 1 2 3 4 5

Were the key inputs easy to use? 1 2 3 4 5 Did the instructions clearly indicate which keys you were to press? 1 2 3 4 5 What is your overall impression of this machine 1 2 3 4 5

Please provide any additional comments or suggestions on the back of this form

22

Appendix B Patron Evaluation Form

Tester Name:___________________________ Date Completed:_________________ Tester Phone #:__________________ Tester Email 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? 1 2 3 4 5 Was it clear and easy how to enter the stall number? 1 2 3 4 5 Was it clear and easy to enter the coins first and not choose the amount of time for payment? 1 2 3 4 5

Was it clear and easy to choose the amount of time to pay for and then insert coins? 1 2 3 4 5

Was it clear and easy to print a receipt? 1 2 3 4 5 Did the receipt have all of the information that you thought was necessary? If not, please comment on what was missing. 1 2 3 4 5

Were you able to cancel the transaction before depositing coins? 1 2 3 4 5 Were the key inputs easy to use? 1 2 3 4 5 Did the instructions clearly indicate which keys you were to press? 1 2 3 4 5 What is your overall impression of this machine 1 2 3 4 5

Please provide any additional comments or suggestions on the back of this form

23

A2

Identify User

Set User globally

A3 S1

Administrator Supervisor

7.1 – Administrator/Supervisor Login (contd.)

Appendix C– Administrator and Supervisor Flowcharts

24

A3

User Input

Display ‘Administrator

Main Menu’ (Fig 7-2-1)

Input Value?

Display ‘Admin Logout’ (Fig 7-2-2)

W1

Display error message (Figure

4-12-4)

0, 4-8, Enter, Arrows9, Cancel

A20A10

1

2

S1

User Input

Display ‘Supervisor Main Menu’ (Fig 7-3-1)

Input Value?


W1


4-12-9)

0, Enter, L & R Arrows

9, Cancel

A20

A10

12

A30

S40 S50

S60

3

4 5

6

S70

7

S80

8

A30

3

Scroll Up One Line

Scroll Down One Line

U ArrowD Arrow

7.2 – Administrator Menu

7.3 – Supervisor Menu

25

A10

User Input

Display ‘Unpaid or Paid Parking Lot

Print Menu’ (Fig 7-4-1)

Input Value?


W1


4-12-3)

0, 3-8, Enter, Arrows

Cancel

A16A11

1 2

User Admin or Super?

A3

Admin

9

S1

Super

A11

User Input

Display Unpaid Stall Number

Menu (Fig 7-4-2)

Input Value?

Display ‘Logout’ (Fig 7-2-2/3)

W1


4-12-3)


Cancel1 2


A3

Admin

9

S1

Super

Query Server for All Unpaid Stall

Numbers

Display ‘Printing’(Fig 7-4-3)

Print Unpaid Stall-Number List(Fig 7-4-4/5)

Display ‘Enter Range’

(Fig 7-4-6)


Numbers in Range

Complex User Input

7.4 – Stall List – A10, A11

7.4-1 – Unpaid Stall List

Range Valid?

Yes

Display error message

(Fig 7-4-7)No

26

A12

User Input

Display Paid Stall Number Menu

(Fig 7-4-8)

Input Value?


W1


4-12-3)


Cancel1 2


A3

Admin

9

S1

Super


Numbers


Print Paid Stall-Number List

(Fig 7-4-10/11)

Display ‘Enter Range’

(Fig 7-4-12)


Numbers in Range

Complex User Input

7.4-2 – Paid Stall List – A12

Range Valid?

Yes

Display error message

(Fig 7-4-7)No

27

A20

User Input

Display Statistics Menu

(Fig 7-5-1)

Input Value?


W1


4-12-5)


Cancel


A3

Admin

9

S1

Super

7.5 – Print Total Parking Lot and Individual Stall Statistics – A20

1 2 4

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)


3

28

A30

7.6 – Correcting System Malfunctions – A30 (functionality not yet designed/planned)

?

29

S40

Display ‘Change/Print system

parameters menu screen display’

(Fig. 7-7-1)

User Input

Input Value?


4-12-6)

0, 6, 7, 8, ENTER, L, R

Scroll Up One Line


Up Arrow

Down Arrow

S1

S41 S42 S43 S44 S45

9

5

43

1

2


Cancel

W1S41

Display ‘Change/print rate-structure

menu screen display’

(Fig. 7-7-1-1)

User Input

Input Value?


4-12-6)

Scroll Up One Line


U

0, 5, 6, 7, 8, ENTER, L, R

D

S41.1

S41.2 S41.3

S41.4

S1

W1


9

Cancel

1 4

2 3

S40, S41

30

S41.1

Display ‘Change in-session rate menu screen

display’(Fig. 7-7-1-1-1)

User Input

Input Value?


4-12-6)

Scroll Up One Line

Scroll Down One LineD

U

0, 6, 7, 8,ENTER, L, R

S41.11

S41.12 S41.14

S41.15

S41.13

51

23

4


W1

S41

CANCEL

9

S41.11

Display ‘Change in-session peak-rate-value screen


Complex User Input

Each digit pressed, screen

shown in Fig. 7-7-1-1-2 updated. ‘L’

removes last number pressed. ‘ENTER’ signifies end completion of

entry

‘0’-‘9’, ENTER, L

S41.1

CANCELDisplay Error

Message (Fig 4-12-1)

D, R, U

Display Error Message

(7-7-1-1-3)Reset entered

display in 7-7-1-1-2

Outside Range

S41.1Inside Valid Range

Update In-session peak-rate value in

database

S41.12

Display ‘Change in-session

shoulder-rate value screen


Complex User Input




entry

‘0’-‘9’, ENTER, L

S41.1

CANCELDisplay Error


D, R, U




Outside Range


Update In-session

shoulder-rate value in

database

S41.1, S41.11, S41.12

31

S41.13

Display ‘Change in-session off-peak rate-value screen


Complex User Input




entry

‘0’-‘9’, ENTER, L

S41.1

CANCELDisplay Error


D, R, U




Outside Range


Update In-session off-peak rate value in

database

S41.14


weekend-rate value screen


Complex User Input




entry

‘0’-‘9’, ENTER, L

S41.1

CANCELDisplay Error


D, R, U




Outside Range


Update In-session

weekend rate value in

database

S41.15

Display ‘Printing in-session rate list message screen


Print In-session Rate values

printout(Fig 7-7-1-1-11)

S41.1

S41.13, S41.14, S41.15

32

S41.2

Display ‘Change/print non-session rate-value menu screen display’(Fig. 7-7-1-2-1)

User Input

Input Value?


4-12-4)

Scroll Up One Line


U

0, 4, 5, 6, 7, 8,ENTER, L, R

S41.21

S41.22

S41.23

1

23


W1

S41

CANCEL

9

S41.21

Display ‘Change non-session

weekday rate screen display’(Fig. 7-7-1-2-2)

Complex User Input




entry

‘0’-‘9’, ENTER, L

S41.2

CANCELDisplay Error


D, R, U




Outside Range


Update non-session

weekday rate value in

database

S41.22


weekend rate value screen


Complex User Input




entry

‘0’-‘9’, ENTER, L

S41.2

CANCELDisplay Error


D, R, U




Outside Range


Update non-session

weekend rate value in

database

S41.2, S41.21, S41.22

33

S41.23

Display ‘Printing non-session rate

list message screen display’(Fig. 7-7-1-2-6)

Print non-session rate values


S41.2

S41.3

Display ‘Change/print holiday-rate

value menu screen display’

(Fig. 7-7-1-3-1)

User Input

Input Value?


4-12-3)

Scroll Up One Line


U

0, 3, 4, 5, 6, 7, 8,ENTER, L, R

S41.31 S41.32

1

2


W1

S41

CANCEL

9

S41.31

Display ‘Change holiday rate screen


Complex User Input




entry

‘0’-‘9’, ENTER, L

S41.3

CANCELDisplay Error


D, R, U




Outside Range

S41.3Inside Valid RangeUpdate holiday

rate value in database

S41.32

Display ‘Printing holiday rate list

message screen display’

(Fig. 7-7-1-3-4)

Print holiday-rate values printout(Fig 7-7-1-3-5)

S41.3

S41.23, S41.3, S41.31, S41.32

34

S41.4

Display ‘Change/print special event rate value menu screen display’(Fig. 7-7-1-4-1)

User Input

Input Value?


4-12-3)

Scroll Up One Line


U

0, 3, 4, 5, 6, 7, 8,ENTER, L, R

S41.41 S41.42

1

2


W1

S41

CANCEL

9

S41.41

Display ‘Change special event rate

screen display’(Fig. 7-7-1-4-2)

Complex User Input




entry

‘0’-‘9’, ENTER, L

S41.4

CANCELDisplay Error


D, R, U




Outside Range


Update special event rate value in

database

S41.42

Display ‘Printing special event rate


Print special event rate values


S41.4

S41.4, S41.41, S41.42

35

S42

Display ‘Change/print rate schedule times menu screen

display’(Fig. 7-7-2-1)

User Input

S42.1

S42.2

S42.3

31

2

S40

W1

CANCEL

9



4-12-4)

Scroll Up One Line


U

0, 4, 5, 6, 7, 8, ENTER, L, R

D

S42

36

S42.1

Display ‘Change/print in-session rate-times menu screen display’(Fig. 7-7-2-1-1)

User Input

Input Value?


4-12-7)

Scroll Up One Line


U

0, 7, 8,ENTER, L, R

S42.11

S42.12

S42.14

S42.15

S42.13


W1

S42

CANCEL

9

S42.11

Display ‘Change in-session peak rate-times value screen display’(Fig. 7-7-2-1-2)

Complex User Input



removes last number pressed. ‘R’ tabs between time fields. U/D selects AM/PM.

‘ENTER’ signifies end completion of

entry.

‘0’-‘9’, ENTER, L, R, D, U

S42.1

CANCEL




Outside Range


Update In-session peak-

rate-times value in

database

S42.16

3

12

45

6

S42.12

Display ‘Change pre-peak shoulder rate-times value screen display’(Fig. 7-7-2-1-4)

Complex User Input





entry.

‘0’-‘9’, ENTER, L, R, D, U

S42.1

CANCEL




Outside Range


Update pre-peak shoulder

rate-times value in

database

S42.1, S42.11, S42.12

37

S42.13

Display ‘Change post-peak

shoulder rate-times value screen


Complex User Input





entry.

‘0’-‘9’, ENTER, L, R, D, U

S42.1

CANCEL




Outside Range



rate-times value in

database

S42.14

Display ‘Change off peak rate-times

value screen display’

(Fig. 7-7-2-1-8)

Complex User Input





entry.

‘0’-‘9’, ENTER, L, R, D, U

S42.1

CANCEL




Outside Range


Update pre-peak shoulder

rate-times value in

database

S42.15


weekend rate-times value screen


Complex User Input





entry.

‘0’-‘9’, ENTER, L, R, D, U

S42.1

CANCEL




Outside Range



rate-times value in

database

S42.16

Display ‘Printing in-session rate-

time list message screen display’

(Fig. 7-7-2-1-12)

Print in-session rate-time values


S42.1

S42.13, S42.14, S42.15, S42.16

38

S42.2

Display ‘Change/print in-session rate-times menu screen display’(Fig. 7-7-2-1-1)

User Input

Input Value?


4-12-4)

Scroll Up One Line


U

0, 4, 5, 6, 7, 8,ENTER, L, R

S42.21

S42.22

S42.23


W1

S42

CANCEL

9

3

1

2

S42.21


weekday rate-times value screen


Complex User Input





entry.

‘0’-‘9’, ENTER, L, R, D, U

S42.2

CANCEL




Outside Range


Update non-session

weekday rate-times value in

database

S42.22


weekend rate-times value screen


Complex User Input





entry.

‘0’-‘9’, ENTER, L, R, D, U

S42.2

CANCEL




Outside Range


Update non-session

weekend rate-times value in

database

S42.2

39

S42.23

Display ‘Printing non-session rate-time list message


Print non-session rate-time values


S42.2

S42.23

40

S42.3

Display ‘Change/print holiday rate-

times menu screen display’

(Fig. 7-7-2-3-1)

User Input

Input Value?


4-12-3)

0, 3, 4, 5, 6, 7, 8,ENTER, L, R, U, D

S42.31

S42.32


W1

S42

CANCEL

9

1

2

S42.31

Display ‘Change holiday rate-times

value screen display’

(Fig. 7-7-2-3-2)

Complex User Input





entry.

‘0’-‘9’, ENTER, L, R, D, U

S42.3

CANCEL




Outside Range


Update non-session

weekday rate-times value in

database

S42.32

Display ‘Printing holiday rate-time


Print holiday rate-time values


S42.3

S42.3, S42.31, S42.32

41

S43

Display ‘Change/print non-permanent

schedule menu screen display’(Fig. 7-7-3-1)

User Input

S43.3 S43.4 S43.5

53

4

S40

W1

CANCEL

9



4-12-7)

Scroll Up One Line


U

0, 7, 8, ENTER, L, R

D

S43.1 S43.2 S43.6

1 2 6

S43.1

Display ‘Change the calendar-year schedule-menu screen display’(Fig. 7-7-3-1-1)

User Input

W1


S43

CANCEL

9

S43.11

S43.12

S43.13 S43.16

S43.17

S43.18


4-12-7)

Scroll Up One Line


U

0, L, R

D

$43.14 S43.15

1 8

2

3

4

7

6

5

S43, S43.1

42

S43.11

Display ‘Change the fall semester

date values screen display’

(Fig. 7-7-3-1-2)

Complex User Input



removes last number pressed. ‘R’ tabs between

time fields. ‘ENTER’ signifies end completion of

entry.

‘0’-‘9’, ENTER, L, R

S43.1

CANCEL




Outside Range


Update the fall semester date values stored in database

S43.12

Display ‘Change the Thanksgiving break date values


Complex User Input





entry.

‘0’-‘9’, ENTER, L, R

S43.1

CANCEL




Outside Range


Update the Thanksgiving

break date values stored in database

Display Error Message (Fig. 4-

12-1)U, DDisplay Error

Message (Fig. 4-12-1)

U, D

S43.13

Display ‘Change the post-fall/pre-spring semester


(Fig. 7-7-3-1-6)

Complex User Input





entry.

‘0’-‘9’, ENTER, L, R

S43.1

CANCEL




Outside Range


Update the post-fall/pre-

spring semester date values stored in database


12-1)U, D

S43.14

Display ‘Change the spring

semester date values screen


Complex User Input





entry.

‘0’-‘9’, ENTER, L, R

S43.1

CANCEL




Outside Range


Update the spring

semester date values stored in database


12-1)U, D

S43.11, S43.12, S43.13, S43.14

43

S43.15

Display ‘Change the spring-break


(Fig. 7-7-3-1-10)

Complex User Input





entry.

‘0’-‘9’, ENTER, L, R

S43.1

CANCEL




Outside Range


Update the spring break date values

stored in database

S43.16

Display ‘Change the post-spring/

pre-summer semester date values screen


Complex User Input





entry.

‘0’-‘9’, ENTER, L, R

S43.1

CANCEL




Outside Range


Update the post-spring/pre-summer



12-1)U, DDisplay Error


U, D

S43.17

Display ‘Change the summer session date values screen


Complex User Input





entry.

‘0’-‘9’, ENTER, L, R

S43.1

CANCEL




Outside Range


Update the summer

session date values stored in database


12-1)U, D

S43.18

Display ‘Change the post-summer/pre-fall semester break date values


Complex User Input





entry.

‘0’-‘9’, ENTER, L, R

S43.1

CANCEL




Outside Range


Update the post-summer/

pre-fall semester

break date values stored in database


12-1)U, D

S43.15, S43.16, S43.17, S43.18

44

S43.2

Display ‘Printing calendar year schedule list


(Fig. 7-7-3-1-18)

Print non-session rate-time values


S43

S43.3

Display ‘Change permanent holiday

schedule menu screen display’(Fig. 7-7-3-2-1)

User Input

W1


S43

CANCEL

9

S43.31

S43.32

S43.33 S43.36

S43.37


4-12-7)

Scroll Up One Line


U

0, L, R

D

$43.34 S43.35

1

2

3

4

7

6

5

S43.38

Display ‘Printing permanent holiday

schedule list message screen


Print permanent holiday schedule


S43.3

S43.2, S43.3, S43.38

45

S43.31

Display ‘Change New Year’s Day

date screen display’

(Fig. 7-7-3-2-2)

Complex User Input




entry.

‘0’-‘9’, ENTER, L

S43.3

CANCEL




Outside Range


Update New Year’s Day date value stored in database

S43.32

Display ‘Change Martin Luther

King’s Birthday date screen


Complex User Input




entry.

‘0’-‘9’, ENTER, L

S43.3

CANCEL




Outside Range


Update the post-spring/pre-summer



12-1)U, D, RDisplay Error


U, D, R

S43.3.3

Display ‘Change Memorial Day Date screen


Complex User Input




entry.

‘0’-‘9’, ENTER, L

S43.3

CANCEL




Outside Range


Update Memorial Day

date value stored in database


12-1)U, D, R

S43.34

Display ‘Change Independence Day date values screen


Complex User Input




entry.

‘0’-‘9’, ENTER, L

S43.3

CANCEL




Outside Range


Update Independence

Day date value stored in database


12-1)U, D, R

S43.31, S43.32, S43.33, S43.34

46

S43.35

Display ‘Change Labor Day date screen display’

(Fig. 7-7-3-2-10)

Complex User Input




entry.

‘0’-‘9’, ENTER, L

S43.3

CANCEL




Outside Range


Update Labor Day date value

stored in database

S43.36

Display ‘Change Thanksgiving Day


(Fig. 7-7-3-2-12)

Complex User Input




entry.

‘0’-‘9’, ENTER, L

S43.3

CANCEL




Outside Range


Update Thanksgiving

Day date value stored in

database


12-1)U, D, RDisplay Error


U, D, R

S43.3.7

Display ‘Change Christmas Day


(Fig. 7-7-3-2-14)

Complex User Input




entry.

‘0’-‘9’, ENTER, L

S43.3

CANCEL




Outside Range


Update Christmas Day

date value stored in database


12-1)U, D, R

S43.35, S43.36, S43.37

47

S43.4

Display ‘Change special event

dates and times screen display’(Fig. 7-7-3-3-1)

Complex User Input



removes last number pressed.

‘R’ used to tab among time/date

fields. ‘U’/’D’ indicates AM/PM.‘ENTER’ signifies end completion of

entry.

‘0’-‘9’, ENTER, L, R, U, D

S43

CANCELDisplay Error

Message(7-7-3-3-2) if date field incorrect, (7-

3-3-3-3) if time field incorrect, (7-3-3-3-4) if AM/PM

flag not set.Reset entered


Outside Range

S43Inside Valid Range

Update special events values

stored in database

S43.5

Display ‘Printing special event schedule list


(Fig. 7-7-3-3-5)

Print special event schedule printout

(Fig 7-7-3-3-6)

S43

S44.3

Display ‘Printing current active stall

list message screen display’

(Fig. 7-8-5)

Print currently active parking-lot stall number list

printout(Fig 7-8-6)

S44

S45.5

Display ‘Printing current date and time parameter


(Fig. 7-9-5-1)

Print current date and time

parameter number list printout(Fig 7-9-2)

S45

S43.4, S43.5, S44.3, S45.5

48

S44

Display ‘Change/Print parking-lot

size menu screen display’

(Fig. 7-8-1)

User Input

S44.1

S44.2

S44.3

231


4-12-7)

0, 4, 5, 6, 7, 8,ENTER, D, U, L, R

S40


W1

CANCEL

9

S44.1

Display ‘Stall number addition screen display’

(Fig. 7-8-2)

Complex User Input


shown in Fig. 7-8-2 updated. ‘L’ removes last

number pressed. ‘R’ is used to tab

between stall number fields.


entry.

‘0’-‘9’, ENTER, L

S44

CANCEL

Display Error Message(7-8-3)

Reset entered display in 7-8-2

Outside Range


Update stall number values

stored in database


12-1)U, D

S44.2

Display ‘Stall number deletion screen display’

(Fig. 7-8-4)

Complex User Input


shown in Fig. 7-8-4 updated. ‘L’ removes last

number pressed. ‘R’ is used to tab

between stall number fields.


entry.

‘0’-‘9’, ENTER, L

S44

CANCEL



Outside Range


Update stall number values

stored in database


12-1)U, D

S44, S44.1, S44.2

49

S45

Display ‘Modify date and time

schedule menu screen display’

(Fig. 7-9-1)

User Input

S45.3 S45.4 S45.5

53

4

S40

W1

CANCEL

9



4-12-6)

Scroll Up One Line


U

0, 6, 7, 8, ENTER, L, R

D

S45.1 S45.2

1 2

S45.1

Display ‘Change current date

screen display’(Fig. 7-9-1-1)

Complex User Input


shown in Fig. 7-9-1-1 updated. ‘L’


entry.

‘0’-‘9’, ENTER, L

S45

CANCEL

Display Error Message(7-9-1-2)

Reset entered display in 7-9-1-1

Outside Range


Update current date value stored in database


12-1)U, D, R

S45.2

Display ‘Change current time


Complex User Input




entry.

‘0’-‘9’, ENTER, L

S45

CANCEL



Outside Range


Update current time value stored in database


12-1)U, D, R

S45, S45.1, S45.2

50

S45.3

Display ‘Change current leap year

status screen display’

(Fig. 7-9-3-1)

User Input

2

1

S40

W1

CANCEL

9



4-12-3)

0, 3, 4, 5, 6, 7, 8, ENTER, L, R, D, U

Display ‘Leap year indicator flag has been set screen

display’(Fig 7-9-3-2)

Display ‘Non-leap year indicator flag

has been set screen display’(Fig 7-9-3-3)

Update leap year indicator

flag in database

Update non-leap year

indicator flag in database

S45.3

S45.3

51

S45.4

Display ‘Enter daylight savings time beginning/ending dates


User Input

21

S40

W1

CANCEL

9



4-12-3)

0, 3, 4, 5, 6, 7, 8, ENTER, L, R, D, U

S45.41

S45.42

S45.41

Display ‘Enter date to begin daylight

savings time screen display’(Fig. 7-9-4-2)

Complex User Input




entry.

‘0’-‘9’, ENTER, L

S45.4

CANCEL



Outside Range


Update date to begin daylight savings time

value stored in database


12-1)U, D, R

S45.42

Display ‘Enter date to end daylight savings time


Complex User Input




entry.

‘0’-‘9’, ENTER, L

S45.4

CANCEL



Outside Range


Update date to end daylight savings time

value stored in database


12-1)U, D, R

S45.4, S45.41, S45.42

52

S50

Display ‘Modify/print login codes


(Fig. 7-10-1)

User Input

S53 S54 S55

53

4

S1

W1

CANCEL

9



4-12-7)

Scroll Up One Line


U

0, 7, 8, ENTER, L, R

D

S51 S52

1 2

S56

6

S51

Display ‘Enter administrator login code to be added message screen

display’(Fig. 7-10-2)

Complex User Input

Each digit pressed, screen shown in Fig. 7-10-2 updated. ‘L’


‘R’ used to tab between login-code and name fields. ‘ENTER’

signifies end completion of

entry.

‘0’-‘9’, ENTER, L, R

S50

CANCEL



Outside Range


Update administrator login code/

name values stored in database


12-1)U, D

S52

Display ‘Enter administrator login code to be deleted message screen


Complex User Input



‘R’ used to tab between login-code and name fields. ‘ENTER’


entry.

‘0’-‘9’, ENTER, L, R

S50

CANCEL



Outside Range


Update administrator login code/



12-1)U, D

S50, S51, S52

53

S53

Display ‘Printing administrator login code list message

screen display’(Fig. 7-10-5)

Print administrator login code list

printout(Fig 7-10-6)

S50

S54

Display ‘Enter supervisor login

code to be added message screen


Complex User Input


removes last number pressed. ‘R’ used to tab between login-code and name fields. ‘ENTER’


entry.

‘0’-‘9’, ENTER, L, R

S50

CANCEL



Outside Range


Update supervisor login code/



12-1)U, D

S55

Display ‘Enter supervisor login

code to be deleted message screen


Complex User Input


removes last number pressed. ‘R’ used to tab between login-code and name fields. ‘ENTER’


entry.

‘0’-‘9’, ENTER, L, R

S50

CANCEL



Outside Range


Update supervisor login code/



12-1)U, D

S56

Display ‘Printing supervisor login

code list message screen display’(Fig. 7-10-10)

Print supervisor login code list


S50

S53, S54, S55, S56

54

S60

Display ‘Modify/print login codes


(Fig. 7-11-1)

User Input

S61 S62 S63

31

2

S1

W1

CANCEL

9



4-12-7)

Scroll Up One Line


U

0, 5, 6, 7, 8, ENTER, L, R

D

S64

4

S61

Display ‘Change master/server ID number screen


Complex User Input



entry.

‘0’-‘9’, ENTER, L

S60

CANCEL



Outside Range


Update master/server

ID number values stored in database


12-1)U, D, R

S62

Display ‘Change slave/client ID number screen


Complex User Input



two slave/client ID fields. ‘ENTER’


entry.

‘0’-‘9’, ENTER, L, R

S60

CANCEL



Outside Range


Update slave/client ID

number values stored in database


12-1)U, D

S60

55

S63

Display ‘Change parking lot ID

number screen display’

(Fig. 7-11-6)

Complex User Input



entry.

‘0’-‘9’, ENTER, L

S60

CANCEL



Outside Range


Change parking lot ID

number values stored in database


12-1)U, D, R

S64

Display ‘Printing parking system ID

list message screen display’

(Fig. 7-11-8)

Print parking system ID list


S60

S63, S64

56

S70

Display ‘Print/download activities


(Fig. 7-12-1)

User Input

S71 S72 S73

31

2

S1

W1

CANCEL

9



4-12-7)

Scroll Up One Line


U

0, 5, 6, 7, 8, ENTER, L, R

D

S74

4

S71

Display ‘Printing audit information message screen


Print audit information list


S70

S72

Display ‘Printing invalid login attempts list


(Fig. 7-12-4)

Print invalid login attempts list


S70

S74

Display ‘Downloading year-to-date

statistical summary file

message screen display’ (Fig. 7-12-

16)

Send year-to-date statistical summary file to

laptop.

Print year-to-date statistical

summary printout.(Fig. 7-12-17)

S70

S70, S71, S72

57

Appendix D – Software Project Headers ///////////////////////////////////////////////////////////////////////////////////////////////// // DateTimeType.h // // DateTimeType class header ///////////////////////////////////////////////////////////////////////////////////////////////// #include <string> using namespace std; #ifndef DateTimeType_H #define DateTimeType_H class DateTimeType{ private: unsigned int year; // 0-? char month; // 1-12 char day; // 1-31 char hour; // 0-196 char minute; // 0-59 bool pm; public: DateTimeType(); int getYear(); // returns year field char getMonth(); // returns month field char getDay(); // returns day field char getHour(); // returns hour field char getMin(); // returns minute field bool getPM(); // returns a string with DateTimeType in format: // 0) "MM/DD/YYYY HH:MM A/P" // 1) "MM/DD/YYYY" // 2) "HH:MM A/P" // 3) "HHH:MM" string getString(char pFormat); // set each field bool setYear(int pYear); bool setMonth(char pMonth); bool setDay(char pDay); bool setHour(char pHour); bool setMin(char pMin); bool setPM(bool pPM); bool setDate(char pMonth, char pDay, int pYear); // sets date fields bool setTime(char pHour, char pMin, bool pPM); // sets time fields // Operator Overloads DateTimeType operator +(DateTimeType &a); // adds two Times DateTimeType operator -(DateTimeType &a); // subtracts two Times // Comparison operators bool operator < (DateTimeType &a); bool operator <= (DateTimeType &a); bool operator >= (DateTimeType &a); bool operator > (DateTimeType &a); bool operator == (DateTimeType &a); }; class DateTimeRangeType{ public: DateTimeType start, end; }; #endif

58

//RateType.h #include <string> #include "DateTimeType.h" using namespace std; #ifndef RateType_H #define RateType_H class RateType { public: RateType(); //Post: Create a RateType void setTime(DateTimeType Start, DateTimeType End); //Post: set the start time and end time void operator=(const RateType& src); //Post: if the RateType are not the same, then this RateType copy src private: DateTimeType StartTime, EndTime; double Rate; }; #endif

59

//DayRateType.h #include "RateType.h" #include <string> #ifndef DayRateType_h #define DayRateType_h //To make DayType more general typedef string DateType; class DayRateType { public: DayRateType(); //Post: create a DayRateType double GetRateFromTime(DateTimeType pTime); //Post: returns the rate for pTime of this day void setRates(RateType p1, RateType p2, RateType p3, RateType p4); //Post: sets each of the rate periods for the day; only p1 is required private: RateType period[4]; // array of 4 rate periods during day DateTimeType date; // date to which these rates correspond }; int StringTODouble(char* input); //change the string Time type into integer #endif

60

///////////////////////////////////////////////////////////////////////////////////////////////// // StateType.h // // StateType class header ///////////////////////////////////////////////////////////////////////////////////////////////// //#include "stdafx.h" #include <string> #include <iostream> using namespace std; #ifndef StateType_H #define StateType_H class StateType{ public: int ID; // Unique identifier corresponding to state string lines[16]; // array of strings for each line of the display int nextID[16]; // IDs of where each keypress takes the user (16 keys) // if no key press, next state is nextID[0] int waitForKey; // flag that indicates the FSM should block for a single key press // (i.e. a single user key press is required) int scrollable; // flag indicates if display is scrollable // Member functions StateType(); StateType(int); ~StateType(); void display(int pLine); // displays screen on LCD, starting with line pLine StateType& operator=(const StateType &s); }; #endif

61

///////////////////////////////////////////////////////////////////////////////////////////////// // StateCollectionType.h // // StateCollectionType class header // contains a collection of StateType objects ///////////////////////////////////////////////////////////////////////////////////////////////// // this should probably utilize a dynamic array, because it will only be filled once, at startup. // the group could resize the array once, by reading the number of items in the file // or the group could add them one at a time, resizing as the group go //#include "stdafx.h" #include "StateType.h" #ifndef StateCollectionType_h #define StateCollectionType_h class StateCollectionType{ private: int size; // number of elements in collection StateType* collection; // dynamic array of StateTypes public: StateCollectionType(); void setSize(int pSize); // sets collection size, i.e. resizes array bool loadFromFile(string path); // loads collection from a text file StateType getState(int pStateID); // returns the StateType object with ID=pStateID friend StateType readStateFromFile(ifstream &f); }; #endif

62

///////////////////////////////////////////////////////////////////////////////////////////////// // admin.h // // Administrative (Administrator and Supervisor both) UI header // contains functions that complete an entire Administrative function ///////////////////////////////////////////////////////////////////////////////////////////////// void AdminLogin(); // A1-(A3 or S1) void AdminStallList(bool pPaid, char pSelectRange); // A11 // Print stall list // pPaid: True = print paid list, False = unpaid list // pSelectRange: True = Prompt user for stall range, False = print list for all stalls void AdminPrintStatistics(char pFormat); // prints statistics report (A20) // pFormat = // 1) Lot Stats by Time (fig 7-5-3) // 2) Lot Stats by Num of Users (fig 7-5-5) // 3) Stall Stats by Time (fig 7-5-7) // 4) Stall Stats by Num of Users (fig 7-5-9) ///////////////////////////////////////////////////////////////////////////////////////////////// // customer.h // // Customer functions // contains functions that complete an entire customer activity ///////////////////////////////////////////////////////////////////////////////////////////////// int CustWelcome(); void CustAddTimeRequest(); // C3-W1 void CustExpirationTimeRequest(); // C7-W1 void CustAddTimeByCoin(); // C11-W1 //double TotalInserted = 0.00; //double LastCoin = 0.00; //TimeType TotalTime = 0; //TimeType StartTime = getCurrentTime(); //RateType CurRate = GetRate(StartTime); //while(1) //{ // if(key press) // { // if(cancel) // { break; } // else // { Display_Error(); } // } // else if(coin inserted) // { // LastCoin = CoinValue(); // read value of coin from coin acceptor // TotalInserted += LastCoin; // add it to running total // // CurRate = GetRate(StartTime + TotalTime); // Get rate at end of current paid period // // TimeAdded = GetTimeFromRate(LastCoin, CurRate.Rate); // get time value for coin at current rate // TotalTime += TimeAdded; // add time value to running time total // // Update display with new TotalTime // } //}

63

///////////////////////////////////////////////////////////////////////////////////////////////// // supervisor.h // // Supervisory (Supervisor only) UI header // contains functions that complete an entire Administrative function ///////////////////////////////////////////////////////////////////////////////////////////////// // --------------------- S41 ------------------------------------------------------------------ // Change Rate Values void SuperRegularRateValueChange(bool pInSession, char pRate); // S41.11-14, S41.21-22 // pInSession: True = change the in-session rate // pRate: 1) Peak 2) Shoulder 3) Off-peak 4) Weekend // // pInSession: False = change the out of session rate // pRate: 1) Weekday 2) Weekend 3&4) <Do Nothing> void SuperRegularRateValueListPrint(bool pInSession); // S41.15, S41.23 // pInSession: True = print the in-session rates, False = print the out of session rates void SuperSpecialRateValueChange(bool pHoliday); // S41.31, S41.41 // pHoliday: True = change holiday rate, False = change special event rate void SuperSpecialRateValueListPrint(bool pHoliday); // S41.31, S41.41 // pHoliday: True = print holiday rate, False = print special event rate // --------------------- S42 ------------------------------------------------------------------ // Change Rate Times void SuperRegularRateTimeChange(bool pInSession, char pRate); // S42.11-15, S42.21-22 // pInSession: True = change the in-session rate time // pRate: 1) Peak 2) Pre-peak Shoulder 3) Post-peak Shoulder 4) Off-peak 5) Weekend // // pInSession: False = change the out of session rate time // pRate: 1) Weekday 2) Weekend 3&4) <Do Nothing> void SuperRegularRateTimeListPrint(bool pInSession); // S42.16, S42.23 // pInSession: True = print the in-session rate times, False = print the out of session rate times void SuperSpecialRateTimeChange(); // S42.31 // change holiday rate time void SuperSpecialRateTimeListPrint(); // S42.31 // print holiday rate time // --------------------- S43 ------------------------------------------------------------------ // Change Calendar Dates void SuperCalendarChange(char pID); // S43.11-18 // Change the dates of... // pID: // 1) fall semester // 2) thanksgiving break // 3) post-fall/pre-spring break // 4) spring semester // 5) spring break // 6) post-spring/pre-summer break // 7) summer session // 8) post-summer/pre-fall break void SuperCalendarPrint(); // S43.2 // Print the calendar year schedule void SuperPermHolidayChange(char pID); // S43.31-37 // Change the dates of... // pID: // 1) new year's // 2) MLK birthday // 3) memorial // 4) independence // 5) labor // 6) thanksgiving // 7) christmas void SuperPermHolidayPrint(); // S43.38 // Print the permanent holiday schedule

64

void SuperSpecialEventChange(char pMode); // S43.4 (to be added) // Modify special events using mode... // pMode: // 1) Add // 2) Modify // 3) Delete void SuperSpecialEventPrint(); // S43.5 // Print the special event list // --------------------- S44 ------------------------------------------------------------------ // Change Stall Numbers void SuperStallNumberChange(char pMode); // S44.1-2 // Change stall numbers by.. // pMode: // 1) Addition // 2) Deletion void SuperStallNumberPrint(); // S44.3 // --------------------- S45 ------------------------------------------------------------------ // Change Current Date/Time void SuperCurrentDateChange(); // S45.1 void SuperCurrentTimeChange(); // S45.2 void SuperLeapYearChange(); // S45.3 void SuperDaylightSavingsChange(bool pBeginEnd); // S45.4 // pBeginEnd: // True = Begin date // False = End date void SuperCurrentDateTimePrint(); // S45.5 // --------------------- S51-3 ------------------------------------------------------------------ // Change User Codes void SuperUserCodeAdd(); // S51 void SuperUserCodeDel(); // S52 void SuperUserCodePrint(); // S53 // --------------------- S60 ------------------------------------------------------------------ // Change Master/Slave IDs void SuperSystemIDChange(char pID); // S61-2 // pID: // 1) Master ID // 2) Slave ID // 3) Parking Lot ID void SuperSystemIDPrint(); // S63 // --------------------- S71-4 ------------------------------------------------------------------ // Print statistical summaries void SuperAuditInfoPrint(); // S71 void SuperInvalidLoginAttemptsPrint(); // S72 void SuperCustTransFilePrint(char pDay); // S 73 // pDay: // 1) Monday // 2) Tuesday // 3) Wednesday // 4) Thursday // 5) Friday // 6) Saturday // 7) Sunday

65

// 8) Whole Week void SuperStatSummaryDownloadPrint(); // S74

66

//////////////////////////////////////////////////////////////////// // COIN ACCEPTOR // need to look at the driver source files (interrupt or polling?) double coinValue(); // returns dollar value of last coin inserted TimeType GetTimeValueOfCoin(double pCoin, RateType pRate); // returns the time value of a coin pCoin at rate pRate bool UserPromptInsertCoins(double TotalCost); // Prompts user to insert coins until TotalCost has been reached ///////////////////////////////////////////////////////////////////////////////////////////////// // keypad.h // // Keypad interaction functions ///////////////////////////////////////////////////////////////////////////////////////////////// // define special keys #define U 10 #define D 11 #define L 12 #define R 13 #define E 14 #define C 15 char keyTranslate(char pRawKey); // returns actual character from the raw ASCII value produced by keypad char getKey(); // uses keyTranslate() to get a single keypress from the keypad (like getchar()) void shiftLeftAndAdd(int pLength, int * pArray, int pNewDigit); // base 10 shifts pNumber left, and then adds pNewDigit // e.g. pNumber=32, pNewDigit=8, return=328 void shiftRight(int pLength, int * pArray); // base 10 shifts pNumber right one // e.g. pNumber=243, return=24 int charToInt(char c);

67

///////////////////////////////////////////////////////////////////////////////////////////////// // LCD.h // // LCD display functions ///////////////////////////////////////////////////////////////////////////////////////////////// #include <string> using namespace std; string format40(string pContent); // returns pContent formatted to fit screen size void display(string pContent); // displays Content on the LCD void displayLine(int ID, string s); // displays pContent on line pLine void displayInvalidKeyError(char pID); // displays invalid key error for 3 seconds, then returns LCD to previous state ("<pID> is an invalid choice") void displayPrintingStatus(string pTitle); // displays "Printing 'TITLE' \n Thank You' void displayDownloadStatus(string pTitle); // displays "Downloading 'TITLE' \n Thank You' void displayThankYou(); // display "Thank You" for 3 seconds, then return to previous screen //////////////////////////////////////////////////////////////////// // PRINTING void print(string pContent); // prints string to printer string printHeader(); // returns string with "Parking Lot Number XX \n DATE at TIME \n\n" // function for each printout void printUnpaidStallsList(StallRangeType pRange); void printPaidStallsList(StallRangeType pRange);

68

//RateCalc.h #include <iostream> #include <string> #include "../classes/RateType.h" #include "../classes/DayRateType.h" #include "../classes/DateTimeType.h" double RateCalc( DateTimeType Start, DateTimeType End); // returns dollar amount required for time Start to time End

69

#include "..\classes\system.h" #include "..\classes\DateTimeType.h" //#ifndef curUser_global //#define curUser_global //UserType curUser; //#endif //-------------------------------------------------------------------------------------- Stall expire times // Get and set stall expire time //check for valid stall number, return true if valid (A1) bool IsStallNoValid(int pStallNo); DateTimeType GetStallExpireTime(int pStallNo); // Returns expiration time of pStallNo, or #0:00# if past (utilityfunction) bool SetStallExpireTime(int pStallNo, DateTimeType pNewExpireTime, double money, int slaveID); // sets the expiration time of stall pStallNo in the master database // return true if successful, false if not // (utility function - to be used by "Add Time" menus string PrintStallExpireList(int pStart, int pEnd); // Returns a list of unpaid stalls in the range pStart-pEnd as a string (see SFD) //-------------------------------------------------------------------------------------- User Authentication // Validate user code UserType ValidateUser(int IDcode); // return UserType object for login code pLoginCode // if login code is invalid, return code=pLoginCode, name="", userLevel=invalid // else if valid, return code=pLoginCode, name="user's name", userLevel=ADMIN or SUPER void LoginAttempt(string username, bool isValid); //added function, for stastical tracking, will be called from ValidateUser // Add or delete user codes void AddUser(UserType user); // see user.h for data struct void DelUser(UserType user); //-------------------------------------------------------------------------------------- Statistics // 1) Lot Stats by Time (fig 7-5-3) // 2) Lot Stats by Num of Users (fig 7-5-5) // 3) Stall Stats by Time (fig 7-5-7) // 4) Stall Stats by Num of Users (fig 7-5-9) // // 5) Audit Information // 6) Invalid Login Attempts (Retrieve) // 7) Customer Transactions by Day in Prev Week // 8) Customer Transactions for Prev Week // 9) Year-to-Date Summary // For these, write a function that returns a string with these stats // formatted as they are in the last part of // section 7 of Software Functional Description. Please fill this in // yourselves. string PrintStats(int x); // x corresponding to 1-9 above. (retrieve only). //-------------------------------------------------------------------------------------- Rate Information // Set In-session (Peak, Shoulder, Off-peak, Weekend) and Out-of-Session (weekday, Weekend) // Rate Values, Times // 8-day Array //DayRateType* PopulateRateArray(); // Returns a pointer to an array of 8 DayRateType objects for the next 8 // days of rate information // Change Rate Values

70

void RegularRateValueChange(bool pInSession, char pRate, double pValue); // S41.11-14, S41.21-22 // pInSession: True = change the in-session rate // pRate: 1) Peak 2) Shoulder 3) Off-peak 4) Weekend // // pInSession: False = change the out of session rate // pRate: 1) Weekday 2) Weekend 3&4) <Do Nothing> string RegularRateValueListPrint(bool pInSession); // S41.15, S41.23 // pInSession: True = print the in-session rates, False = print the out of session rates void SpecialRateValueChange(bool pHoliday, double pValue); // S41.31,S41.41 // pHoliday: True = change holiday rate, False = change special event rate string SpecialRateValueListPrint(bool pHoliday); // S41.31, S41.41 // pHoliday: True = print holiday rate, False = print special event rate // Change Rate Times void RegularRateTimeChange(bool pInSession, char pRate, DateTimeType pTime); // S42.11-15, S42.21-22 // pInSession: True = change the in-session rate time // pRate: 1) Peak 2) Pre-peak Shoulder 3) Post-peak Shoulder 4) Off-peak 5) Weekend // // pInSession: False = change the out of session rate time // pRate: 1) Weekday 2) Weekend 3&4) <Do Nothing> string RegularRateTimeListPrint(bool pInSession); // S42.16, S42.23 // pInSession: True = print the in-session rate times, False = print the out of session rate times void SpecialRateTimeChange(DateTimeType pTime); // S42.31 // change holiday rate time string SpecialRateTimeListPrint(); // S42.31 // print holiday rate time //-------------------------------------------------------------------------------------- Calendar Information // Set semester, break start and end dates // Set special event start and end dates and times // Set holiday dates void SetCalendarDate(int pID, DateTimeType pDate); // ID corresponds // Change the dates of... // pID: // 1) fall semester // 2) thanksgiving break // 3) post-fall/pre-spring break // 4) spring semester // 5) spring break // 6) post-spring/pre-summer break // 7) summer session // 8) post-summer/pre-fall break string CalendarPrint(); // S43.2 // Print the calendar year schedule void SetHolidayDate(int pID, DateTimeType pDate); // ID corresponds // Change the dates of... // pID: // 1) new year's // 2) MLK birthday // 3) memorial // 4) independence // 5) labor // 6) thanksgiving // 7) christmas void HolidayPrint(); // S43.38 // Print the permanent holiday schedule

71

void AddSpecialEvent(DateTimeType pStart, DateTimeType pEnd, double pRate); void SpecialEventPrint(); // S43.5 // Print the special event list //-------------------------------------------------------------------------------------- Current Time Information // Set current date, time, leap year, and daylight savings void SetCurrentDate(DateTimeType pDate); void SetCurrentTime(DateTimeType pTime); string PrintCurrentDateTime(); // Returns the current date and time in a string void SetLeapYear(bool pIsLeap); void SetDaylightSavingsStart(DateTimeType pDateTime); void SetDaylightSavingsEnd(DateTimeType pDateTime); //-------------------------------------------------------------------------------------- System Information // Set parking lot, master IDs // Add/Remove Stall Ranges void SetMasterID(int ID); int GetMasterID(); void SetParkingLotID(int ID); int GetParkingLotID(); void AddStallRange(int pStart, int pEnd); void DelStallRange(int pStart, int pEnd); string StallRanges(); // Prints a list of valid stall ranges //-------------------------------------------------------------------------------------- Update Software // The program files will be downloaded from the server upon every startup of a slave // A single function will reboot if the time recorded in a server text file is greater than a local text file void RebootIfReqd(string pPathToTimeFile);

72

///////////////////////////////////////////////////////////////////////////////////////////////// // stateAction.h // // Handles special actions for certain states ///////////////////////////////////////////////////////////////////////////////////////////////// // UI functions //#include "..\UI\userInput.h" // User Input (includes keypad, LCD) #include "..\UI\customer.h" // Customer #include "..\UI\admin.h" // Administrator #include "..\UI\supervisor.h" // Supervisor #include "..\IO\keypad.h" #include "..\IO\LCD.h" // Handles complex actions for a given state // PRE: pStateID contains the State ID for which to act // POST: returns the next State ID int stateAction(int pStateID);

73

///////////////////////////////////////////////////////////////////////////////////////////////// // parkingMeter.cpp // // Entry point of parkingMeter application ///////////////////////////////////////////////////////////////////////////////////////////////// #include "stdafx.h" #include "classes\StateCollectionType.h" // State classes #include "classes\system.h" // Settings and User struct defs //#include "classes\DayRateType.h" // Rate classes #include "modules\stateAction.h" // GLOBAL VARS char userChoice=0, curLine=1; int curStateID=0, prevStateID=0; // state vars StateType curState; StateCollectionType states; //DayRateType NextWeek[8]; // global array of rate information for 8 days int _tmain(int argc, _TCHAR* argv[]) { char exit=0; states.loadFromFile("c:\\statesNew.txt"); // begin state machine loop while(!exit) { //// STATE INITIALIZATION //// curState = states.getState(curStateID); // load state info from collection curLine = 0; curState.display(curLine); // display screen for this state // CALL SPECIALITY FUNCTIONS FOR CURRENT STATE //// stateAction(curStateID); // USER INPUT / NEXT STATE LOGIC //// if(curState.waitForKey) { userChoice = getKey(); // get user input if required //// SCROLLING KEY CHECK //// if(curState.scrollable) { while(userChoice == U || userChoice == D) { if(userChoice==U) { curLine ++; } else if(userChoice==D) { curLine--; } curState.display(curLine); // wait for next keypress userChoice = getKey(); } } if(userChoice>-1) // check if key value is correct DEBUGGING { // save previous state prevStateID = curStateID; // set state to corresponding nextState of user's choice curStateID = curState.nextID[userChoice]; }

74

//// INVALID KEY CHECK //// if(curStateID == -1) // invalid state due to invalid key press { displayInvalidKeyError(userChoice); // display error for 3 secs curStateID = prevStateID; // return to previous state } } else { // save previous state prevStateID = curStateID; // if not a menu, the next state is indicated by element 0 curStateID = curState.nextID[0]; } } }

Prototype Parking Meter System – Phase 3 Status...

Documents

Transcript of Prototype Parking Meter System – Phase 3 Status...