Abstract:

e-ParkTrak is the project proposed by Senior Design group 14. This project is taking on a serious problem that exists at Stevens Institute of Technology…. Parking. We are proposing to try to alleviate the congestion in the campus parking lots by the change of rules and regulation associated with the privilege of parking on Campus. Our approach is to build upon the existing techniques currently used for parking at School by making enforcement of the rules easier for the police officers to perform. In addition, new rules concerning students and faculty would be made in association with the campus Police and administration.

Our system will consist of either magnetic coded or barcode verification permits that have a unique identifier associated with them. We will most likely use the barcodes though due to the relatively lower cost of that type of system. Our System will be Web based and will be administered via the web for maintenance and accessible to users of the system for purpose of requests of additional time and for other statistical functions.

e-ParkTrak will be implemented by using a hand held computer that can communicate to a base unit via wireless LAN technology. Issuance of citations will be electronic by either purely electronic means (e-mail), printed paper from the hand held, or by some combination of both

We fully expect to be able to produce a working prototype of this device by the end of the Spring semester, though some modifications may need to be implemented due to budget constraints.

Introduction:

Our project is titled e-ParkTrak. It consists of components such as the Handspring Visor, Epson EHT-40, hand held bar code scanner devices, network infrastructures, as well as several different computer software packages participating in various job issues. Our project is geared towards trying to fix a general problem experienced at Stevens Institute of Technology... parking. Many people park their cars for hours at a time in the Stevens parking lots, though many do not have class at those times. This action takes parking spots away from those that spend many minutes, sometimes up to an hour, looking for parking, eventually leading them to be late to class, or even miss the class altogether. Some students resort to illegal parking, risking summons, or worse yet, being towed. We have come up with a general solution to this problem. We propose to extend the current parking system by equipping each student’s parking permit with an electronic identification. This identification would be in the form of either magnetic coding or barcode. Each of these solutions would allow scanning by a portable wireless hand held device to verify the parked car. At this time we lean toward barcodes due to that solution costing less. In this plan each student who buys a permit will be issued a sticker or tag that is barcoded for identification, most likely a decal would be placed on a window of the registered vehicle. Police officers would be able to verify the validity of the parking permit, identify the vehicle, and assess the permissibility of that vehicle in the zone that it is parked in through the use of our hand held device. Once validity of the vehicle is determined, the officer could issue warnings or summonses. This could all be done in the electronic domain by issuing electronic citations, by attaching a printer to the hand held device for printing tickets, or by a hybrid combination of both.

Present state of the industry

At this time the parking verification system that we propose is not unique, but is rare. Only a few companies exist that have implemented electronic ticketing and parking control. Some companies that exist in this field are Electronic Data Collection Company (EDC), with their Automated Issuance and Management System (AIMS), NetTech Solutions with ParkTech 2000, and T2 Systems, Inc. with PowerPark and ePark. In general all of these systems incorporate paper citation issuance, permit registration, and a direct connection to a computer database. Each system also integrates a hand held device such as the Radix RX-1 (shown on the left) as a mobile input device. All of these systems offer its own unique feature, for instance AIMS incorporates plate lookups and vehicle identification, while ParkTech 2000 has an integrated software modular system for customization.

Other solutions to parking lot problems include point of entry solutions. These systems are generally controlled by a gating system, whereby some form of identification opens the gate. A magnetic reader or barcode scanning system most often controls these systems. One of the major companies involved in this kind of system is Barcode Automation Incorporated (BAI) with their BA-200 Barcode Reader. This reader will read barcode labels on vehicles up to 6 feet from the reader moving at up to 25 mph (shown below).

Group 14 proposes to raise the bar on these systems with the integration of a World Wide Web interface into the parking system database. Provisions for electronic payment and rules customization will be implemented into our system as well. We will work with the Police department and administration closely in the design of rules for parking on campus and for those rules that may be altered as well. Additionally, temporary paper barcoded permits could be issued with our system, which could be very beneficial to the school when having events, or when other off campus people are invited to the school.

The inclusion of the World Wide Web interface to control this system will ensure access to the Police officers, administrators, students, faculty, as well as the public so that parking requests and ticket payments could be made. Rules for parking would also be available on this page so that those involved with the system would understand exactly what is required of them. Statistical information and other customizations could be made and displayed here as well as per the contract made with the campus for development of this system. Between the rules that we establish and tighter enforcement control using our system, the goal of more parking should be achieved.

The inclusion of zoning and timing is really what sets our system apart from the others. e-ParkTrak will allow vehicles with certain permits to park in particular zones for certain amounts of time, depending on the schedules and rules laid out for that particular permit. This system allows for complete parking lot customization. This kind of system will be easily adapted to other facilities and municipalities with minimal customization.

Design Requirements:

Group 14 intends to improve the parking situation at Stevens Institute of Technology. We will develop a system that allows for complete enforcement control of parking rules and regulations through electronic means for the purpose of reducing parking lot congestion. This system will incorporate a hand held computer device that patrolmen can carry with them into parking lots. These devices will be able to communicate with a base station either by interactive wireless means, or by a batch system and linkup. A network infrastructure will be setup consisting of a portable workstation (hand held), base station (pc), switches, hubs and cables. TCP/IP would be used as the base protocol with the possibility of a custom protocol on top of TCP/IP. Each semester students will be required to submit a copy of their class schedule for entry into the system, or ideally, the registrar will make their database accessible to our database for more precise and up to date information. Additionally, students will be asked to submit information about their vehicle, such as make and model of the car, license plate number, place of residence during the semester, and possibly a copy of their license and registration. All of the information gathered from the students will be verified and entered into the e-ParkTrak database. If any information about a student changes with the manual system, the student will be able to log into the e-ParkTrak web site for Stevens and enter their new information (direct link to the registrar would allow instantaneous information updates). Guest access to the web site could also be allowed for the granting of temporary permits. This system allows Stevens to be aware of whether a vehicle is allowed to be on campus or not. It would also be able to track the amount of expected traffic in the lots and when this traffic is expected to occur. As long as the police does its job with enforcement and use of our system, there should be a noticeable difference in the parking lots

Requirements for this project include hand held interface and programming, wireless communications, protocol design, database design, and web based user interface design. The Basic wireless network design diagram follows:

Design Approaches:

Hardware considerations

In developing e-ParkTrak we are considering basically two approaches for the coding of the physical permits, magnetic coding technology similar to an ez-pass type system and barcode. We are currently leaning very strongly toward barcodes due to its relatively low associated cost. That being said, we are considering a few options regarding barcode scanners. The market for hand held computers varies from full fledged pc’s in a small box such as the Epson EHD-40 (left) to devices traditionally used as pda’s such as a Handspring Visor (below). Each of these devices can be equipped for barcode scanning and connections to pc’s. The full-fledged computers will more easily meet the needs of our project, because of their ease of expandability but at a much higher cost. Another option for the mobile device is a Notebook computer that would likely remain in a vehicle, but would then require a long range barcode scanner such as the Soltec Vision scanners, which can read barcode information from as far away as 40 feet. Additional information about barcodes can be found in appendix A. The wireless side of the project requires that the there be communications between the hand held devices and the base unit so that wherever the Police officers are, they will be able to access the main base and subsequently the database. From communications with other Senior Design groups that have tested wireless LANs on campus, our understanding is that two base stations are required, one at the upper campus (Howe Center) and one at Lower campus (Police station). Testing of the coverage and reliability of wireless LANs is a major part of our project that will help determine whether we go with the wireless solution or batch processing solution.

Managing System Data

The system should hold all data in a relational database management system. Other possibilities would be a flat file system, holding data all together in one table (non-relational database management system), or having operators who look up the data themselves. A flat file system is very slow and can also be unreliable if concurrency issues are not taken care of (this is difficult, takes much time to implement, and unnecessary if another option is used). Holding data together in one table is slower than holding it in a relational (more than one table that are linked through relations) database, makes it very difficult to change the database structure, and is actually more complicated than having multiple tables. Instead of having to fix the data so that it fits within one table, the data can be structured in a way that is intuitive to use. Having operators look up data themselves would be too slow for our system (the police officer would have to wait too long between cars), would be prohibitively expensive (consider salaries), and is prone to error. (Error is something we want to minimize). So, from the options listed above, the only one that will be seriously considered is holding all data in a relational database system. The question is which one.

The decision of what database software to use can be narrowed down to one that uses the SQL language (Structured Query Language). This is a language that has been developed to retrieve and store data from and to a relational database system. There are many interfaces available that will allow the use of SQL from C, C++, perl, and some other languages. This is an industry-accepted standard and the relational database systems that are considered “the best” all use it. There are many SQL databases on the market and they all differ in costs, license agreements, data capacity, certain SQL language extensions, and speed for different operations. Costs, license agreements, and SQL language extensions that could be useful all can be researched on the Internet. Data capacity, and operation speeds can be measured via a benchmark. There are many benchmark suites and many can be found for free. We can also rely on benchmarks performed by others. (This might be a cheaper alternative). We must also consider what operating system we want to run on as the type of software and the benchmark is dependent on it.

The two most industry accepted operating systems for database suites is Microsoft™ NT and Linux©. We need to look at reliability, speed, cost, ease of use, scalability (in case we want to expand the system in the future), and security. (We don’t want to allow the system to be tampered with and since this system deals with law enforcement, it is a likely candidate for crackers).

The Webpage Software

The system also calls for a webpage that is linked to the database. The choice of web server software again depends on the operating system. The most used piece of web server software is Apache© for Linux© so this will be given strong consideration. Questions to consider are speed, reliability, how many requests a second can be handled without overloading the system, cost, and security.

Software needs to be designed to interface the webpage with the database. The most common choices are C, C++, Perl, or ASP. This is software that is run when a web user tries to view a page on his browser. The web server software starts the program and the program queries the database (or it can send data to it, or both), formats the data to its liking, and sends the information back in the form of HTML (a format that the user’s web browser can use to show the page to the user). One thing to consider is ease of programming this type of application in the programming language. One must remember that to interface with the database, one must use an API. This is a set of functions that allow the programmer to easily use the database from within his programs. Thus a question to consider is how easy is the API to use. There are some APIs that work with any database system and others that only work with one, but APIs usually only work with the programming language they were designed for. The programming languages listed above have numerous APIs designed for them. Other things to consider are again speed, reliability, and security.

Interface Between Police Officer And Base System (Base System Side)

The officer’s equipment ultimately needs to interface with the database since the database holds the information as to whether the vehicle is legally parked. The database can be directly accessed in two ways: A piece of software could be using an API, or the SQL port can be opened on the computer thus allowing a device to communicate directly to the database in SQL via TCP/IP (the basic Internet protocol). A device commercially designed for checking inventory might have the ability to directly access the database, but more than likely it will use some other form of communication in which case we need to use the API interface to the database. A piece of software will than be used to intercept the data from the device (whether it be from a card on the computer, or communication through the network card either from the device or some other device acting as a router. All options need to be considered including costs, distance, reliability, and scalability (how many scanners would the system be capable of handling at one time).

Database and Web, Together

The database software and the web software can be on the same machine or different machines. The question is cost and scalability. In a large-scale system, the database could span several machines and several web servers could be clustered thus splitting a large volume of web activity among different web servers servicing the same information.

The website together with the database will allow easy updates to information and will also allow general users to have access to information. Administrators will be able to update the times when certain people are allowed in certain lots (for people who are exempt somehow from the general rules) and to change general rules about what criteria students must meet to park in a lot at a certain time without special permission. When new parking permits are issued, the information can be inserted via the administrators’ webpage. Student and teachers’ class information could be retrieved from another system or could be manually inserted via the web page. The advantage of using another system would be reliability, and fewer labor costs. General users could use the web page to find out when they need to renew their parking privileges, what their parking privileges are, and whether they owe any money for tickets. Unpaid tickets could be a criterion to whether people lose parking privileges. (An administrator could set this up as a rule). Email notifications can go out to users in the case of certain events. Updates to the system are relatively easy since most of the system is software based.

Database and Scanner, Together

The scanner reads a number on a vehicle and sends it to the database. For the police officer to know whether the vehicle is legally parked, that information must be returned back to the scanner. Tickets could be given out electronically and no information would have to be sent back, but then no ticket could be placed on the car and there would be no check to make sure that people haven’t “traded parking permits” (discussed shortly). If all that is sent to the database is the permit number then the least information that could be sent back would be what lots the car was allowed to be parked in. The officer would have to check to see whether the lot he was in was one of them listed, if not, then he would write a ticket. For the system to know whether a ticket was issued it would have to be inserted later or the device would have to have some way of sending this information. If the officer could key in the lot he was in, then the system could return whether the vehicle is legally parked or not and the system would also have an immediate record of the violation. The system could have a way to cancel tickets just given in case the officer forgets to enter the fact that he just switched lots and wrongfully accused a parked vehicle of being illegally parked.

Other information the system could send back is the license plate number or even perhaps a description of the car. This prevents people from swapping permits with someone else, and that someone else parking somewhere he doesn’t have the right to. This information would be used to stop this type of fraud.

Financials:

The following Spreadsheet shows the preliminary proposed costs associated with developing e-ParkTrak. These are very rough estimated costs at this time due to the possibility of going in several different directions with chosen hardware and software. Labor costs are very rough as well, and is based on a $50.00 per hour basis. Actual costs are sure to be less.

Financial Cost:

Materials and Parts
Software:	Product ID	Cost Per Seat
	Linux Operating System	$ 73.53
	Microsoft Frontpage	$ 97.97
	Borland C++ Builder V5.0 Standard	$ 89.95
	Apache Web Server	$ 100.54
	Intellitrack Software, Single User Inventory	$ 995.00
	Module, Tracking Program

Hardware:	Handspring Visor	$ 250.00
	Portable Data Collector wireless scanner	$ 1,499.00
	Magnetic Bar Codes
	3Com 10/100 Fast Ethernet switches -12 port	$ 428.00
	3Com 10/100 Fast Ethernet Hub - 12 port	$ 439.00
	Laptop	$ 2,497.79
	Network cables:
	12 port Wallmount patch panel	$ 59.95
	Network 7ft Cat5 cables	$ 82.68	per cable
	APC 25Pk Velcro cable tie black	$ 26.23	per package of 25 cables

Documentation	Paper for the wireless scanner printer	$ 38.72
Cost:	Copy Vendor documentation	$ 5.00	50 copies at $0.10 per copy

Support Staff:	Phone calls to the vendor for information	$ 6.00	30 minutes at $0.20 per minute
	Phone calls to companies for troubleshooting	$ 9.00	45 minutes at $0.20 per minute

Labor Costs:	200 hours at $50.00 per hour	$ 10,000.00

Web Based Parking Varification System

	Proposal		October 29, 2000

	Table of Contents:
		• Abstract	• Project Schedules
		• Introduction	• Conclusion
		• Present State of Industry	• References
		• Design Requirements	• Appendix A
		• Design Approaches	• About Barcodes
		• Financials	• Barcode Samples