• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Design
 

Design

on

  • 339 views

 

Statistics

Views

Total Views
339
Views on SlideShare
339
Embed Views
0

Actions

Likes
0
Downloads
2
Comments
0

0 Embeds 0

No embeds

Accessibility

Upload Details

Uploaded via as Microsoft Word

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Design Design Document Transcript

    • Software Design Specification RFID Parking Garage Matt Nichols Tony Nichols Contact E-Mail: anichol9@gmail.com March 11, 2008
    • 1.0 Introduction Finding parking spaces for automobiles and motorcycles can be a problematic venture due to limited space and time, while the selling of parking spaces is potential lucrative endeavor. Currently, most large parking garages, including airport parking, use a ticketing system in which users get a time-stamped ticket when entering the structure and pay a time-relative fee when exiting. The transmission of these disposable tickets is a time inefficient process, susceptible to error. These tickets can easily be lost; and with the lost tickets, the entire process becomes disoriented. The manual payment process can also be time consuming when traffic is at a high rate. An RFID (radio-frequency identification) parking system would improve this by allowing the user to interact with the parking area with an RFID card at the entrance and exit of the parking area. An RFID parking system would also allow the user to keep an account on which the system would keep track of financial transactions. This would reduce the amount of time the user must interact with the system and increase the security of the user. As an added security feature, an electronic keypad will be placed at the entrance of the parking garage. Once the user has swiped their RFID card they will enter their pin number. The pin number and the unique ID on each RFID card will be used to validate the user. 1.1 Goals and objectives • To provide individuals who require a parking area a system that is efficient and easy to use. • To provide individuals with a system that accounts for the length of each visit and provide them an account that will be used to pay for the visit. • To determine the adaptability of an RFID parking system in different situations
    • • To determine the feasibility and cost effectiveness of an RFID parking system that provides efficiency and ease of use. • Improve security over conventional RFID parking systems by adding a keypad for user authentication. 1.2 Statement of scope The user will be provided an RFID card and an online account which they will use to gain access to the parking area and pay for each visit. When the user is ready to enter the parking area, they will place the card within a close proximity to the RFID reader. The proximity will vary depending on the model of the RFID implementation. A unique ID is transmitted from the card to the reader. The reader then transmits the unique ID to the database. In addition to scanning their card, the user will also enter his pin number into the keypad. The system will validate the user and record the time of entry. A signal is then sent to the entrance by the system to allow the user to enter the parking garage. Upon leaving, the user will repeat the same process that he used to entering the garage. The system will record that the user is exiting the parking area and record the time of exiting. The user is then charged the appropriate amount for the visit and the amount is made visible on his account. The user can then login to his account and make a payment on his balance. 1.3 Software context In order to resolve the issue, we must change both the way that customers access the parking garage and how money is transferred between the building owner and the customer. A simple and accessible technology like Radio Frequency Identification (RFID) cards and readers could be employed in order to streamline the entry and exit process. The cards would be tied to customer accounts, to which money could be transferred using a web interface. This new process would grant users virtual immediate entry and exit from the parking structure because the
    • transaction is electronically automated. The garage owner would seamlessly receive correct payment. The process would begin with the user requesting an account through the web interface. This web interface will need to be easy to understand and navigate. After creating an account and receiving a unique RFID card in the mail, the user could deposit money into their account for payment in the parking garage(s) connected to the system. As a user vehicle passes the RFID reader at a garage entrance, the card would be read in order to retrieve account information. If the account balance was above the required minimum, the vehicle would be granted access. When leaving the garage, the RFID reader at the exit would read the user’s RFID card and deduct an appropriate amount of money from the user’s account. This process of entry and exit can be streamlined to avoid the lines associated with the current parking garage procedure. The system would be able to count the number of vehicles in the structure at any one time, and know the amount of free parking spaces, if any, present. 1.4 Major constraints • The system development cost for the initial prototype should not exceed $500. • The final sales cost should be competitive with other typing products and specialized numeric keypad devices that are on the market at the time of sale. • The system should withstand periodic cleaning with a damp cloth and mild detergent. • The system should maintain functionality when introduced to an outside environment. • The system should not contain hazardous materials. • The system should maintain functionality when used repetitively by elementary school aged children.
    • • The system should not interfere with the operation of the personal computer to which it is attached. • The system must comply with Part 15, entitled "Radio Frequency Devices" of Title 47 of the Code of Federal Regulations. • The system keypad should be ergonomic in design so that the occurrence of repetitive stress injuries is minimized. • The system must not expose the user to electrical shock.
    • 2.0 Data design 2.1 Temporary data structure A temporary file is created when a user scans their RFID card at the garage will contain a hash of their RFID reference number, name, and password. A separate program will scan the database for the same information and verify the information. Once the information is verified the users are granted access into the garage. 2.2 Database description The database will store an account holder’s information. This information consists of their name, address, phone number, e-mail address, balance, account status, password, pin number, and RFID reference number. Most of this information can be updated at any time while on the user is logged in on the garage website.
    • 3.0 Architectural and component-level design 3.1 Program Structure The RFID parking system for our project resembles that of an event-driven architecture. When an individual arrives at the parking garage, they will scan their RFID card to request access to the parking garage. If the individual is registered with the system and has an active account then they are permitted into the garage. The same can be said for the website that is in development right now. A user will enter their username and password to request access to the website, and if they are a registered user then they are granted access to the website and granted permissions based on their access level. Any action that takes place while the user is logged onto the system is processed and the appropriate action is done. 3.1.1 Architecture diagram Keypad Digit Entry RFID card scan Process card swipe, login information , User/Admin etc login/logoff Database Update Modify Database Account Info Process Funds 3.1.2 Alternatives A possible other architecture design we considered but did not agree suited this project was the broker architecture. The various
    • parts of the architecture would be the user acting as the client, the broker acting as the RFID scanner, and the supplier as the parking garage. But this architecture would only fit for the parking garage aspect of the project and not encompass the website for the parking garage system. The user of the system would have direct access to the website and not have to go through a mediator for information regarding the parking garage systems because the information is provided from the database. 3.2 Description for Component Keypad Digit Entry 3.2.1 Processing narrative for component Keypad Digit Entry The keypad digit entry is done upon arrival at the parking garage gate following the RFID card scan. The digit entry is an added layer of security for access into the parking garage where the user will enter their 3-5 digit password. The information they enter is stored in a temporary file which is then compared to the database information. If the information is correct then the user is granted access into the parking garage. Otherwise they are denied access. 3.2.2 Component Keypad Digit Entry interface description. The input interface is the keypad device found at the entry gate of the garage. The user will enter their password and it is processed by the database for authorization. The output will come from the parking garage light which is represented by a green for access and red for denial. 3.2.3 Component Keypad Digit Entry processing detail 3.2.3.1 Interface description The interface will consist of the numbers 0 through 9 found on any keypad entry device.
    • 3.2.3.2 Algorithmic model (e.g., PDL) Incorrect Password Correct Entry Grant Access to garage 3.2.3.3 Restrictions/limitations • The password is limited to a 3-5 digit password. This can be changed pending if the parking garage administrator wants a longer entry. • Access to the garage if the information is correct. • Denial to the garage if the information is incorrect. 3.2.3.4 Local data structures No data structure is needed for this device. 3.2.3.5 Performance issues • The database should provide the user with access/denial to the garage in a reasonable amount of time, no more then 5-10 seconds.
    • 3.2.3.6 Design constraints • 3-5 digit password • Individuals are allowed five attempts before they must contact the garage administrator for troubleshooting. 3.3 Description for Component RFID Card Scan 3.3.1 Processing narrative for component RFID Card Scan The RFID card scan is the first thing an individual does upon arrival at the parking garage. The individual will scan their card at the RFID reader and then enter their digit password (described in section 3.2). After the user is done at the garage, they will arrive at another RFID reader which they will scan their card again which will mark their departure from the garage. 3.3.2 Component RFID Card Scan interface description. The RFID card scan interface is simply the RFID readers found at the entrance and exit gates of the garage. 3.3.3 Component Keypad Digit Entry processing detail 3.3.3.1 Interface description The interface for this device is the RFID card reader.
    • 3.3.3.2 Algorithmic model (e.g., PDL) Scan failed / rescan Card Scan Scan successful 3.3.3.3 Restrictions/limitations • Card must be in close proximity for the RFID reader to pick up the signal. This will vary pending on the reader and card used. • The card must be kept in good condition otherwise it might not scan at the gate. 3.3.3.4 Local data structures No data structure is needed for this device. 3.3.3.5 Performance issues • The database should provide the user with access to the keypad in a reasonable amount of time. 3.3.3.6 Design constraints N/A
    • 3.4 Description for Component Admin/User Login/Logoff 3.4.1 Processing narrative for component Admin/User Login/Logoff The Admin/User Login/Logoff is relevant for the website. Any registered user of the system may login to the system via the Internet. If a normal user of the system logs onto the system then they be able to view information that pertains to their account. This includes their account balance, garage parking history, and update account information. An administrator of the system will be capable of viewing anything about the parking garage system. This includes registered users, pricing, garage information, and garage statistics. The administrator will also be allowed to view account information of the users and update specific information that is allowed by the design of the system. Afterwards both the user and administrator will have the option to log out when they are finished on the website. 3.4.2 Component Admin/User Login/Logoff interface description. The input interface will include two fields, one for the username and one for the password. They will enter each into the appropriate box and press “Login” to continue. If they are a registered user of the system and the information entered is correct, they are granted access to the garage website. The left side of the screen will contain all the links the users and administrators will have and include a link to “Logout”. Pressing this link will log the user off the website.
    • 3.4.3 Component Admin/User Login/Logoff processing detail 3.4.3.1 Interface description The interface will contain two fields, one for the username and one for the password. Once they are logged onto the system they will have a link on the left side of the screen from which to logout. 3.4.3.2 Algorithmic model (e.g., PDL) Enter Username and Password Throw error Grant Access to message and website prompt to reenter information 3.4.3.3 Restrictions/limitations • Users are allowed five attempts to login before they are locked out of the system and must contact an administrator. • Username will be the e-mail address they used to register. • Password must be between 8-30 characters. 3.4.3.4 Local data structures
    • No data structure is needed for this device. 3.4.3.5 Performance issues • The database should provide the user with access/denial to the garage website in a reasonable amount of time, no more then 5-10 seconds. • Logging onto the system may be slow if many users are trying to gain access to the website. 3.4.3.6 Design constraints • 8-30 character password • Individuals are allowed five attempts before they must contact the garage administrator for troubleshooting. 3.5 Description for Component Modify Account Information 3.5.1 Processing narrative for component Modify Account Information Users of the system are allowed to modify account information. This includes their e-mail address, password, home address, phone number, and name. This is to ensure that users of the system can change information if the need arises. If users wish to update this information, a link on the left side of the screen is provided labeled as “Update Account Information”. If users wish to update their password or e-mail address, then they must enter the information twice to ensure the e-mail address and password are identical. Administrators will also be allowed to update this information but only if the user calls and requests the information change. 3.5.2 Component Modify Account Information interface description. The interface to update the account information will be a series of boxes that will ask the user to input the required information. A
    • series of checks is performed once the user clicks the “Update” button to ensure the information is in the right format, e.g. the password must be 8-30 characters, if the user does provides too few or too many characters an error message will display. 3.5.3 Component Modify Account Information processing detail 3.5.3.1 Interface description The interface will contain various boxes for the user to enter their information. As stated in 3.5.1, if a user wishes to change their e-mail address or password then they must verify them by entering the information twice. 3.5.3.2 Algorithmic model (e.g., PDL) Update Account Information Error: Account Not Updated. Account Updated (Erroneous information) 3.5.3.3 Restrictions/limitations • Users must provide correct information to update their account. • Faulty data is flagged by the administrator and they attempt to contact the individual to correct
    • it. If data is not correctly in 24 hours, their RFID card may be suspended until they correct it. • Password must be 8-30 characters • E-mail address and password must be entered correctly twice. 3.5.3.4 Local data structures No data structure is needed for this device. 3.5.3.5 Performance issues • Updating account information may be slow if many users are trying to gain access to the website and view it. 3.5.3.6 Design constraints • 8-30 character password • E-mail address must contain @<provider>.com notation. 3.6 Description for Component Process Funds 3.6.1 Processing narrative for component Process Funds Users of the system will also have the ability to add funds to their account or have it charged directly to their credit card. To ensure that this information is kept safe, the parking garage system will include VeriSign Identity Protection. This measure is used to protect users of the system from having their accounts fraudulently used. A user will logon to the garage website and click the “Financial Page” to view their payment history and to add funds to their account. This is to ensure that users of the system can scan their card and gain immediate access to the parking garage and go about their business.
    • 3.6.2 Component Process Funds interface description. The input interface will include boxes for the user to enter their credit card information or add funds directly from their bank account (similar in nature of PayPal). If the information entered is correct, the funds are added otherwise an error message will display alerting the user of the mistake made. 3.6.3 Component Process Funds processing detail 3.6.3.1 Interface description The interface will contain boxes for the user to enter information regarding their credit card or add funds from their bank account. 3.6.3.2 Algorithmic model (e.g., PDL) Add Funds Funds Error: Invalid Successfully Account Added information 3.6.3.3 Restrictions/limitations • Must provide a valid account number. • Must provide a valid dollar amount.
    • 3.6.3.4 Local data structures No data structure is needed for this device. 3.6.3.5 Performance issues • Adding funds to the users account may be slow if many users are trying to gain access to the website. 3.6.3.6 Design constraints • Must enter an amount as xxx.xx format. 3.7 Software Interface Description. 3.7.1 External machine interfaces At this time, this system will not need to interface to other machines. 3.7.2 External system interfaces Users and Administrators of the system may connect to the website via an Internet connection at any time. The RFID scanner will connect to the database via USB cables and process the information through the database interface. 3.7.3 Human interface The human interface is described in further detail in section 4.0. Overall the design of the interface that users and administrators will see will be a very simple and easy to use interface. It will allow users and administrators of the system a way to view account information or garage information.
    • 4.0 User interface design 4.1 Description of the user interface 4.1.1 Screen images • Login – user will provide a username and password to gain access to the website. This page will also provide a means to new users to register. • User Home Page o View Account – provides their account information. o Financial Page – provides payment options, current balance, and payment history. o Modify Account – provides a means for the user to modify account information. • Admin Home Page o View Users – list all the users currently registered for the garage and allow them to view account information. o Modify User Information – provides the admin with a means to modify the user’s account with some restrictions. o Garage Statistics – provides the administrator with general statistics of the garage usage. o Garage Options – provides the administrator with a means to modify attributes with the garage i.e. name, price, open or closed, and parking times. At this time screenshots of these pages are unavailable but are currently in development and will be available for viewing later.
    • 4.1.2 Objects and actions • Login o The login screen will provide users a box where they will input their user name and password. The information they enter is validated through the database. • User Home Page o This page will provide general information for the user and provide links to view financial information and to modify their account. The user will also have the ability to log out from this screen. • Financial Page (User Page) o User will be able to view their current balance and specify a payment method. • Modify Account (User Page) o User will be able to modify attributes with their account including address, e-mail address, password, phone number, and name. • Admin Home Page o This page will provide general system information for the administrator and provide links to modify garage information, modify users, view users, and view garage statistics. The user will also have the ability to log out from this screen. • View Users (Admin Page) o Provides the administrator with a list of users currently subscribed to their garage system. This page will also provide links to modify specific user information.’ • Modify User Information (Admin Page)
    • o This page is linked from the View Users page and provides the administrator with the ability to modify a user’s information. • Garage Statistics (Admin Page) o This page will provide the administrator with the amount of users currently parked in the garage, available parking, state of the parking system, total number of users. • Garage Options (Admin Page) o This page will provide the administrator with a means to modify attributes about the garage. This will include a name, price to park, when users will be allowed to park in the garage, and to open/close the garage. 4.2 Interface design rules • Website must be easy to use and maintain. • All web pages with this system will follow the same template. • Web pages must be efficient and cache friendly. • Web pages should be easy to read and navigate. • All information provided on the website must be up-to-date. • Website must provide security from malicious attacks. 4.3 Components available No components are needed at this time. 4.4 UIDS description Ruby on Rails provides a scaffolding option which allows for a basic website creation. With this ability we are able to take those basic templates and modify them to suit our needs. The use of HTML and cascading style sheets can also be used with the Rails system which will provide basic users and administrators and easy to use and read website.
    • 5.0 Restrictions, limitations, and constraints • The system development cost for the initial prototype should not exceed $500. • The final sales cost should be competitive with other typing products and specialized numeric keypad devices that are on the market at the time of sale. • The system should withstand periodic cleaning with a damp cloth and mild detergent. • The system should maintain functionality when introduced to an outside environment. • The system should not contain hazardous materials. • The system should maintain functionality when used repetitively by elementary school aged children. • The system should not interfere with the operation of the personal computer to which it is attached. • The system must comply with Part 15, entitled "Radio Frequency Devices" of Title 47 of the Code of Federal Regulations. • The system keypad should be ergonomic in design so that the occurrence of repetitive stress injuries is minimized. • The system must not expose the user to electrical shock. • The system must not store the users’ credit card information. • Pin number must be 5 digits • System must be easily maintained and updated by parking garage employees. • The system must require minimal modification/updates once implementation is complete.
    • 6.0 Testing Issues 6.1 Classes of tests • Sub-systems Testing o RFID Reader Test – an RFID card is placed near the RFID reader. The card is read and the data is sent to the server. o Add/Remove User - A user is created or removed on the admin webpage. o Gate Test – A signal is sent to the gate control circuit which activates the opening of the gate. The gate remains open until the user has entered the parking garage and begins the closing cycle. o User/Administrator Login – A user or administrator attempts to login to the website using their username and password. o Keypad Test – A pin number is entered into the keypad and transmitted to the server. • System Testing o General Test – User attempts to access the parking garage via an RFID card and keypad. This is a general test of the overall system response. The main purpose of the test is to determine the status of the RFID reader, the keypad, the database status, and the gate functionality. o Administrator Test – An Administrator attempts to login to the system and perform administrative actions. These actions include: add/remove users, modify user accounts, query the database, check the status of the system, and set parameters and constraints on the parking system. o Web Interface Test - A user attempts to login the web interface and modify their account. These modifications
    • include: Changing email address, modifying address, modifying name, requesting an account, and changing payment options. 6.2 Expected software response • Sub-system Testing o RFID Reader Test – The RFID card’s unique ID is transmitted to the server. o Add/Remove User – User roster is updated accordingly in the database. If a user is added, all fields will be filled in and their status is set to “active”. If a user is removed, their status is set to “inactive” and their account information remains in the database. o Gate Test – When the “open” signal is received, the gate begins the opening cycle. Once the user has entered the garage or a present amount of time has passed, the gate will begin it closing cycle. o User/Administrator Login – The user will be validated by the system by their username and password. o Keypad Test – The user’s pin number is transmitted to the server • System Testing o General Test – System should indicate to the user whether or not they have access and then either grant or deny access to the user. Overall status of the system will be evaluated and approved. o Administrator Test – User information should be modified in the database, information should be queried from the database, and parking garage parameters should be updated.
    • o Web Interface Test – Users account should be modified according the changes that were made or a new user’s account should be created. The new data will be stored in the database.
    • 7.0 Appendices 7.1 Requirements traceability matrix The conditions listed are the components of the system mentioned in section 3. Also listed are several actions that can be conducted in the system. Components of the system are affected by the marked actions in each column. Rules are created by determining what component or components are affected by which action or combination of actions. Rules Key Digit Entry - - - X - - - RFID card scan X - - X X - - Conditions User/Admin Login/logoff - - X - - - - Account Info X X - - - - X Process Funds - X - X X X - New user created X - - - - - - User makes a payment - X - - - - - User/Admin is validated - - X X - - - User enters the garage - - - X - - - Action User leaves the garage - - - - X - - User modifies account - - - - - X - information Admin modifies garage - - - - - - X parameters 7.2 Design metrics to be used Standard Design metrics for the construction of object-oriented software will be the guidelines by which all modules are constructed. • Efficiency • Complexity • Understandability • Reusability • Testability and Maintainability
    • There will be a high emphasis in the keeping the project simplistic and understandable. This will reduce the amount of time and energy that is spent on the end-user once the project is completed. The reduction of complexity allows a much more efficient learning curve for the users and the administrator of the garage.