CS 411W Lab II

Prototype Product Specification

Date: 02/12/2007

1      Introduction. 1

1.1       Purpose. 1

1.2       Scope. 4

1.3       Definitions, Acronyms, and Abbreviations. 4

1.4       References. 4

1.5       Overview.. 4

2      General Description. 5

2.1       Prototype Architecture Description. 5

2.2       Prototype Functional Description. 7

2.3       External Interfaces. 8

3      Specific Requirements. 10

3.1       Functional Requirements. 10

3.2       Performance Requirements. 19

3.3       Assumptions and Constraints. 20

3.4       Non-Functional Requirements. 21

Appendix. 24

 

List of Figures

 

Figure 1 PAS Hardware. 5

Figure 3  Sample parking area display. 18

 

List of Tables

 

Table 1 Lot Computer Logic. 19

Table 2 Effects of Assumptions, Dependencies, and Constraints on Requirements. 20

Table 3 Effects of Non-critical Component Failure. 23


1        Introduction

1.1   Purpose

The Parking Administration System (PAS) is a product designed for the parking services industry. PAS will enable a parking services business to provide its customers with up-to-date data about available parking areas. PAS will also provide a parking services business with tools to manage parking passes and customer information. The idea, first introduced by team member Josh LaFountain, was born from observations made about the current state of parking at Old Dominion University. Josh observed excessively long lines for decal purchases. He also realized that there was no indication of where a customer could find available parking.

            PAS solves these problems. PAS contains the ability to allow any user to simply renew their current parking decals online instead of waiting in line for a new one each semester. This idea is implemented with Radio Frequency Identification (RFID) technology. PAS will also provide indication of where a person can find available parking. This feature is enabled by simple car counting. The information obtained from counting is then sent to various displays, including the World Wide Web (Web).

            The most innovative feature of PAS will be its ability to perform dynamic analysis on the information it gathers throughout its installed lifetime. PAS will use its information from past parking performance to predict and display current and future trends to the users of the system. For example, PAS will attempt to tell users at what times the parking facilities will be full based on what it knows about the past.

            The word ‘users’ refers to both the administrators and the people who are parking their own cars. In most instances, there is no difference between an administrative user and a regular user. An administrative user of PAS will of course have various controls not available to the general public. These additional controls will provide information about expired parking decals, various parking violations, and the ability to predict trends in such information.

            The best way to describe the PAS system is to walk through the process of a customer using the system. The user will first obtain an RFID enabled decal through parking services. This decal will be displayed in the front window of the car so that it may be scanned upon entering and exiting the parking facilities. Upon activation of the decal by an administrative user, PAS will store information about the car. This information will include the make, year, model, and license plate number of the car. It will also store information about the person such as their name, relationship with the organization, and facility access levels. The expiration date of the decal will be stored based upon the payment amount chosen by the person when they purchase the decal. All of this information is independent of the information in any pre-existing database.

            Upon entering any parking facility, two events will occur. The first event will be triggered when the car passes over a pressure sensitive hose located on the ground at the entrance. This will increment the count of cars currently in the garage, and the number will then be updated on all applicable displays. At the same time, an RFID scanner will be activated above the car. The purpose of the RFID scanner is to read the unique identification number stored on the RFID enabled decal. This number will be compared with the information stored earlier by PAS. Once that information has been retrieved, PAS will determine whether or not the decal is active, inactive, or expired.

            If the decal is active, PAS will next check the facility access level of the decal. To simplify, it will check to ensure that not only is the decal active, but that it is active for this particular parking facility. Parking facilities may be specialized for faculty/staff, students, residents, or any arbitrary category. In the case that the parking decal is valid for this particular facility, the count of valid cars in the garage will be incremented.

            When PAS finds that a decal is inactive, expired, or not valid for the particular parking facility, it will increment the count of invalid cars. Using this method PAS will know not only how many cars are parked in a particular area, but also how many of those cars are actually authorized to be there.

            Anyone viewing the various displays will be able to see the current number of cars in a garage. They will be able to make decisions about where to park based on this information. The PAS web interface makes available additional information such as the historical data and prediction of future capacities throughout the day. Administrative users will have the added ability to view the valid/invalid ratio of cars in a garage.

            When a car exits the garage, the entire process will operate in reverse. The car will pass over the pressure hose on the ground at the exit, which will decrement the number of current cars. Again, an RFID scanner will be activated to read the decal. Upon making similar decisions to those for an entering car, PAS will decrement either the valid or invalid count of cars, as well as the total number of cars. The count will be updated on all applicable displays.

1.2   Scope

The PAS prototype will be kept as close to the real product as possible. The actual garage hardware has been eliminated, and will instead be simulated via a custom event generator. All other aspects of the PAS system will be real. There will be an actual server machine housing a real database and the PASD software, as well as the custom Web interface. The event generator will run on an actual small computer like one would find in the garage. It will simulate the pressure hose and RFID scanners which the computer would otherwise control.

 

1.3   Definitions, Acronyms, and Abbreviations

1.3.1      PASD

1.3.2      PHP

 

1.3.3      VGA

 

1.3.4      TCP/IP

 

1.3.5      API

 

 

1.4   References

All figures were made by Michael Hall of the Blue Team.

 

 

1.5   Overview

This product specification details the configuration of the PAS prototype. The remaining sections provide the hardware and software configuration, external interfaces, capabilities and features of the PAS prototype.

2        General Description

2.1   Prototype Architecture Description

PAS (the prototype) is comprised of the following major hardware components:

Figure 1 PAS Hardware

The remaining hardware of the PAS system, for the purposes of the prototype, will be simulated with event generation software hosted on the demonstration laptops. For more information on the event generation software please see Page (REMEMBER TO INSERT A PAGE NUMBER HERE!!!!!!!!! DO NOT LEAVE IN FINAL DRAFT BLANK!!!!!).

PAS (the prototype) is comprised of the following major software components:

2.2   Prototype Functional Description

The major functional components of the PAS prototype include the following:

2.3   External Interfaces

2.3.1      Hardware Interfaces

·        Network Interface

o       The network interface will be available to both the central server and the remote computers, allowing them to communicate with each other. PAS will implement the Ethernet interface and protocol.

 

·        Display Interface

o       The display interface for the PAS prototype will be a standard VGA connection from the two (2) laptop computers to two (2) of the flat screen monitors mounted on the wall of the demonstration area.

 

 

2.3.2      Software Interfaces

·        PHP Database Interface

o       The PHP database interface will combine information from the database into the web pages that are seen by client and client customers.

·        PASD Database Interface

o       The PASD database interface will allow communication between the PASD software and the database independent of all other PAS systems.

·        Remote Computer Interface

o       The remote computer interface will enable communication between the central server and the remote computers.

·        Display Interface

o       The display interface will enable the remote computers, via the hardware display interface, to drive the displays seen at each of the parking areas.

 

2.3.3      User Interfaces

 

User interaction with PAS will be through a Web based system. Users will have access to various Web pages which will allow them to lookup information contained in the database about themselves, the current state of the parking areas, and historical information.

 

2.3.4      Communications Protocols and Interfaces

 

PAS will utilize the standard TCP/IP networking protocol using standard Ethernet interfaces for both the central servers and the remote servers.

 

3        Specific Requirements

3.1   Functional Requirements

3.1.1      Homepage

This function shall provide the starting place for the Web based interface for both administrators and users. The following functional requirements shall be provided:

1.      The homepage will display basic system information

a.       Name of business

b.      Aggregate system status (System is up / System is down)

2.      Navigation Menu

a.       Display historical data

b.      Display current data

c.       Online parking decal renewal

3.      Login Capability

a.       Username and password input boxes for access to administrative functions

3.1.2      Historical Data Display

This function, linked from the homepage, will allow users to lookup information about past parking area trends. The following functional requirements shall be provided:

1.      Navigation Menu

a.       Return to previous page

b.      Return to homepage

2.      Login Capability

a.       Username and password input boxes for access to administrative functions

3.      Lookup Function

a.       Input for a specific date and parking area

b.      Input for a specific date

c.       Input for a specific date, parking area, and time

4.      Graphing Function

a.       Once data has been retrieved from database and analyze, a graph shall be displayed to present the information

 

 

 

3.1.3      Current Data Display

This function, linked from the homepage, will provide the user with the current status of a parking area. The following functional requirements shall be provided:

1.      Selection of parking area to view

 

3.1.4      Online Parking Decal Renewal

This function, linked from the homepage, shall provide the user a method of renewing their current parking decal. The following functional requirements shall be provided:

1.      Authentication of User

a.       Input area for ID

b.      Input area for license plate number

2.      Payment Information

a.       Payment system to be handled by third party

3.      Renewal Information

a.       Selection for length of renewal

4.      Verification Screen

a.       Summarizes users update, including suggestion to print page for their records

 

3.1.5      Administrative Page

This functionality, accessible only after login, will allow authorized users to make changes to PAS. The following functional requirements shall be provided:

1.      Navigation Menu

a.       Parking area management

b.      User management

c.       Decal management

d.      Customer management

2.      System Status Display

a.       Display PASD status

b.      Display network connectivity status

c.       Display database status

d.      Display remote computer status

 

3.1.6      Parking Area Management Page

This function shall provide administrative users with an interface for managing the various parking areas. The following functional requirements shall be provided:

1.      Selection

a.       Add parking area

b.      Edit parking area

c.       Delete parking area

2.      Add Parking Area

a.       Input area for parking area name

b.      Input area for parking area capacity

c.       Selection for parking area classification

d.      Input area for IP address of remote computer

3.      Edit Parking Area

a.       Input areas as above, already filled in with previous information

4.      Delete Parking Area

a.       Selection for parking area

b.      Confirmation dialog

 

3.1.7      User Management

This function shall provide administrative users the ability to manage the PAS administrative user list. The following functional requirements shall be provided:

1.      Selection

a.       Add user

b.      Edit user

c.       Delete user

2.      Add User

a.       Input area for username

b.      Input area for user password

c.       Input area for first name

d.      Input area for last name

e.       Selection for user level

3.      Edit User

a.       Input areas as above, already filled in with previous information

4.      Delete User

a.       Selection for user

b.      Confirmation dialog

 

3.1.8      Decal Management

This function shall provide a means for administrative users to perform manual data entry tasks in regard to parking decals. The following functional requirements shall be provided:

1.      Selection

a.       Add decal – current customer

b.      Add decal – new customer

c.       Lookup decal

d.      Edit decal

e.       Deactivate decal

2.      Add Decal – current customer

a.       Customer information already in database, add new decal number to customer’s record

b.      Input area for decal number

3.      Add Decal – new customer

a.       Customer information not already in database

b.      Input area for decal number

c.       Input areas for customer information

4.      Lookup Decal

a.       Input area for decal number

b.      Display customer information for decal

5.      Edit Decal

a.       Input areas as above, already filled out with previous information

6.      Deactivate Decal

a.       Input area for decal number

b.      Confirmation dialog

 

3.1.9      Customer Management

This function shall provide administrative users the ability to control the data in the customer database. The following functional requirements shall be provided:

1.      Selection

a.       Add customer record

b.      Lookup customer record

c.       Edit customer record

d.      Delete customer record

2.      Add Customer Record

a.       Input area for customer ID

b.      Input area for customer name

c.       Input area for customer phone number

d.      Input area for customer address

3.      Lookup Customer Record

a.       Input area for customer ID

b.      Input area for customer name

4.      Edit Customer Record

a.       Input areas as above for add customer record already filled with previous data

5.      Delete Customer Record

a.       Input area for customer ID

b.      Input area for customer name

c.       Confirmation dialog

3.1.10 Parking Area Display

This function shall provide the display of capacity at parking areas. The following functional requirements shall be provided:

1.      The display will driven by the remote computers

2.      The display will be formatted as in Figure 2.

a.       Parking area at which display is located at top position

b.      All other parking areas below

c.       Name of parking area on left, spaces available on right

Figure 2  Sample parking area display

 

3.1.11 Lot Computer Logic

This function shall provide the necessary logic for the lot computers to determine what action to take on a per car basis. The requirements in Table 1 shall be provided:

 

Condition

Action

Car Entrance / Valid Decal

 

Increment total car counter

Increment valid cars counter

Car Entrance / Expired Decal

Increment total car counter

Increment invalid cars counter

Car Entrance / Invalid Decal

(not for this lot type or not in the database at all)

Increment total car counter

Increment invalid cars counter

Car Exit / Valid Decal

Decrement total car counter

Decrement valid cars counter

Car Exit / Expired Decal

Decrement total car counter

Decrement invalid cars counter

Car Exit / Invalid Decal

(not for this lot type or not in the database at all)

Decrement total car counter

Decrement invalid cars counter

Table 1 Lot Computer Logic

3.2   Performance Requirements

3.2.1      PAS Database

The PAS database, hosted by MySQL, shall meet the following performance requirements:

            1. The design of the tables and queries should be such that no single query takes longer than one second to return.

 

 

 

3.3   Assumptions and Constraints

Condition

Type

Effect on Requirements

Vehicles cannot occupy more than one space

Constraint

Bounds the problem of matching vehicle entries and exits to available spaces

Not more than one vehicle can traverse a single entrance or exit in less than one second

Assumption

Allows for RFID reader, and therefore event generator, to dependably send one (and only one) ID/event in the specified time period

Vehicles cannot display more than one decal

Constraint

Bounds the RFID reader, and therefore event generator, to reading/generating one ID number at a time

A smartcard reader is available for the prototype demonstration

Dependency

The Smartcard reader is being used to simulate the pressure hose and RFID reader during the first part of the demonstration.

Table 2 Effects of Assumptions, Dependencies, and Constraints on Requirements

 

 

 

 

3.4   Non-Functional Requirements

3.4.1      Security

Security for the PAS system shall be implemented by the user of username/password combinations and access level controls. Only users with administrative access to the system will be issued usernames and passwords. These users will be assigned levels based on the amount of access required or authorized (i.e. data entry, full system management, etc.). Sensitive information will not be accessible to users without such types of access. In addition, all administrative access pages will be configured to be accessible only on the local network.

 

            The payment information of all users will not be stored in the PAS database. Instead, all payment information will be processed through a third-party payment system such as Paypal or Google Checkout. These are pre-established and trusted Internet based payment systems and not only reduce our liability, but also provide easy to use APIs.

 

3.4.2      Maintainability

The PAS system will require two levels of maintenance. The first level can be covered by a single systems administrator who will be skilled enough to install update patches, monitor the central server and remote computers, and fix networking issues. The second level will require a person skilled in repairing and replacing hardware present in the parking areas.

 

3.4.3      Reliability

The effect of a PAS system failure is dependent upon the extent of the failure. The flow of traffic into and out of the parking areas must not be hindered by the PAS system. If a parking area should experience a failure, that parking area would no longer be able to keep track of the cars passing through. When PAS recovers from the failure, the information contained in the database will refer to the state of the system prior to the failure. In order to completely reset a parking area, the area must be emptied and the counters set to their initial states (zero). Such failure shall also be noted in the database records. Data surrounding a PAS failure should not be included when performing analysis because the data may be inaccurate.

For this reason, the reliability of the PAS system is of extreme importance. Items critical to the functionality of the system are:

·         Central server

·         PASD

·         Lot computers

·         Lot hardware

o       RFID scanners

o       Pressure hoses

With these elements functioning, the critical tasks of collecting data and maintaining the integrity of the collected data are carried out.

            The following elements are considered non-critical:

·         MySQL

·         PHP

·         Apache

·         Network

The table below explains methods used to handle failures of non-critical components.

Component

Handling

MySQL

If the MySQL database is unavailable to PASD, it will store the SQL commands and submit them, in the order it originally would have, when the MySQL database becomes available.

PHP

If the PHP processing engine is unavailable, all web interfaces will be inaccessible. However critical functionality is not affected.

Apache

If the Apache Web server is unavailable, all web interfaces will be inaccessible. However critical functionality is not affected.

Network

If the network fails, the lot computers will store the updates they would normally send to the central server. When the network becomes available they will send their updates in the order in which they would have normally occurred.

Table 3 Effects of Non-critical Component Failure

 

 

Appendix

Preliminary Database Tables:

 

RFID

(primary key)

Active?

Valid

Categories

Expiration

Date

Resource record

(foreign key)

o       Faculty

o       Resident

o       Evening

o       Commuter

o       Village

 

 

Resource Record

(foreign key)

Student/Faculity

ID

Student/Facility

Information

(name, address, phone #)

 

 

Car Information

ID #

(primary key)

Year

Make

Model

Color

License

Multiple cars for one RFID tag.

This will have up to three cars

under this table.

 

 

Garage/Lot

# of Spaces

 

 

Category ID

Category Index

 

 

Garage/Lot

Category ID

 

 

Timestamp

Garage ID

Capacity

 

RFID

(primary key)

Dereference the RFID number to

get all vehicles under the RFID

 

Car Information

ID #

(primary key)

Equipment, software, and materials requirements for prototype: