Download MDR Report - UMass Amherst

Team 19 HP-ID MDR Report (DRAFT)
1
HP-ID: Handicap Parking Identification
Mark Page, EE, Andrew Baraby, CSE, David Joy, EE, and Redwan Alzain, CSE
Abstract—HP-ID is system that will address handicap
parking abuse using active RFID tags embedded in
dashboard placards. Our parking meter will automatically
validate the dashboards RFID tag and will alert the
authorities via Wi- Fi that someone is parked illegally in
real time. Our parking meter will quicken the response
time of parking authorities and thus maintain handicap
parking availabilities for those who are authorized to use
them.
I. INTRODUCTION
ANDICAP parking spots are always the best spots on the
block, you don’t need to worry about walking far, they
are free to park in, and most people have enough moral
fiber to leave these spots available for those who really need
them. However, there are some that see these spots as just
another parking spot that is fair game and take advantage of
the spots.
72% of an estimated 43 million people who rely on
handicap spots have reported being affected by handicap
parking abuse [10]. Seattle authorities report that abuse of
handicap placards cost the city almost 1.4 Million dollars a
year [2]. Due to the simplicity of the placards and lack of
enforcement they are very easy to counterfeit and it is just as
easy to get away with it. In California 1 in 16 drivers use
handicap placards, this is more than double the ratio
nationwide of disabled parkers [8]. This high ratio is
indication of how prevalent fake placards are in California. It
is also difficult to take expired placards out circulation; unless
you turn in your expired placard to the DMV or get caught
using an expired one there is no way to filter out old placards.
In Boston it was found that 1 in 20 placards being used were
registered to people who had passed away [1].
Enforcing abuse of handicap placards is daunting task for
most police and parking authorities. Handicap placards
themselves are simply laminated pieces of plastic that hang
from the rear view mirror. In Massachusetts placards have an
identification number, expiration date, picture ID and name
displayed on them, however the picture ID and name can be
covered with a privacy sleeve [4]. In some states there isn’t
even an expiration date displayed, which makes filtering out
expired placards nearly impossible.
Handicap parking enforcement has changed little despite all
the technological advances in the past few decades. For the
most part, in order to get caught a parking attendant or cop
walking by needs to notice your placard is expired or notice
that you don’t have one at all. Handicap placard sting
operations have become more common as abuse still continues
to proliferate. Cops will ask the driver of the car who the
H
M. A Page from Littleton, Ma (e-mail: [email protected]).
D. Joy from Amherst, Ma (e-mail [email protected]).
A. Baraby from Amherst, Ma (e-mail: [email protected]).
R. Alzain from Amherst, Ma (e-mail: [email protected]).
placard belongs to make sure it is being used properly. In
Massachusetts the owner of the placard MUST be in the car at
the time it is parked and when the car leaves [4].
In New Zealand there has been some attempt to modernize
the enforcement system. Parking attendants are given Wi- Fi
connected handheld devices and check the ID number on the
placard to make sure it’s valid and being used properly. This
however is extremely tedious and requires the parking
attendant to go around and manually enter each ID number.
Our system will automate the validation process using
RFID tags and will alert authorities to illegal parking in real
time. This will allow authorities to respond quicker to illegal
parkers so they can issue parking tickets and/or call a tow
truck so the spot will be available for someone who needs it.
With the allure of handicap being so high and the odds of
getting caught so low we hope that our meter’s quick response
time will help deter the mindset of “what are the odds that I’ll
be caught”
Our parking system need to be just as easy to use for the
handicap drivers as the existing system. Ideally we will want
no driver interaction and want to keep the size of the placard
small and lightweight. The RFID reader in the parking meter
will need to recognize the tag through the windshield and over
the entire area of the parking spot. The tag must also protect
the privacy of the user in the same way that modern placards
do. The tag and parking meter must also be power efficient in
that the power supplies do not need to be replaced often.
TABLE I
SPECIFICATIONS
Specification
Placard
Weight
Height
Width
Battery Life
Meter
Weight
Durable
Wi-Fi
Database of registered Users
Value
<1kg
<25cm
<10cm
>6 Months
<3k
All weather proof
Take advantage of 802.11
Must contain fields of all pertinent
information
II. DESIGN
A. Overview
In order to solve the problem of handicap parking abuse, we
plan on implementing different sub-systems into one system.
There are three different physical components: the placard,
Team 19 HP-ID MDR Report (DRAFT)
the meter, and the database. The placard contains a RFID tag.
The meter contains a RFID reader, a Wi-Fi shield, and a
microcontroller.
The first block detects when a car pulls into a spot. We will
use an induction loop to detect the presence of a car. After a
car pulls into a spot, the reader will wait to receive an ID from
a tag. Once the reader receives an ID from a tag, the tag ID
will be sent to a database over a Wi-Fi connection. The Wi-Fi
shield is connected to a Wi-Fi network. The database will
search for the tag ID and check to see if it is valid. If the ID is
valid, the database will tell the micro-controller to allow the
car to park. The micro-controller is the host for the reader and
Wi-Fi shield. If a car has been validated to park, a green LED
will be illuminated to alert the driver. If a car has not been
validated to park, a red LED will be illuminated on the meter.
We are planning on using solar panels to power the meter,
which is why we are paying close attention to power
consumption.
The first block, the induction loop, must be able to detect a
car at least 95% of the time. The second block, the RFID
components, must be able to communicate at 20 ft. 95% of the
time when the tag is directed in the general direction of the
reader. The reader and tag must be small. The tag must have a
lifespan of at least 50,000 transmissions. The tag needs to be
small enough to be mounted on a placard. The reader needs to
be small enough to fit inside of a reasonably small sized
meter. The third block, the micro-controller, needs to have
enough memory to store a program to efficiently perform all
of the meter’s tasks. The WIFI shield needs to be able to be
connected to a WIFI network with a 95% success rate if there
is a WIFI network available. The database needs to have
enough storage to hold all of the tag IDs, Reader IDs,
Expiration Dates, and all of the other ways we could flag an
ID. The power supply needs to be able to supply power to the
meter 99.9% of the time during normal use. If all of the blocks
meet their individual specifications, the overall system will
work very efficiently. All of the individual specifications are
designed to give a handicap person the greatest chance of
finding an available spot. We are trying to make everything
easier for the handicapped.
There are 5 main types of handicap parking abuse. One type
is when someone uses an expired placard. Our system will
prevent this problem because the database will be able to
2
detect whether a placard has expired or not. An expired
placard will not be validated to park in a handicap spot.
Another type of handicap parking abuse is when someone
creates a counterfeit placard. In our system it will be nearly
impossible to counterfeit placards because placards will
contain active RFID tags. The tags will be clone resistant
because they will contain a programmed security algorithm
that the reader will use to communicate with the tag. The third
type of handicap parking abuse is when someone that does not
have a handicap placard parks in the spot. An alert will sent to
the authorities to come and further address the situation. The
fourth type of handicap parking abuse is when someone steals
another person’s placard. Once someone reports a placard
stolen or tries to get a new placard, the old or stolen placard
will be flagged in the database as invalid. The last type of
abuse and hardest type to enforce is when a non-handicap
person borrows a handicap person’s placard temporarily. This
type cannot be prevented in our system and is very difficult to
currently enforce without invasion of privacy. Although this
type cannot be prevented, it will be drastically reduced. A
handicap person will not be able to order a new placard and
give their old one to someone else, because the old placard
will be flagged as invalid in the database. Almost all of the
handicap parking fraud can be eliminated with our system,
which will maximize the chances for a handicap person to be
able to find a handicap parking spot.
There are many design alternatives and different
technologies that we could have used. Instead of using Wi-Fi
we could have used a cellular connection. We decided not to
use a cellular connection because connecting to a cellular
network would require getting a cell phone plan with a cellular
network. We could have also used a sensor to detect a car,
instead of using an induction loop. We decided to use an
induction loop because induction loops don’t have many false
positives or false negatives. Sensors are very sensitive and
something small can set them off. We want our system to
work efficiently and consistently. Another alternative is using
Bluetooth instead of RFID. Bluetooth requires pairing and is
used in systems that require constant connection. This constant
connection requires a constant power supply. Also, Bluetooth
doesn’t have a long range. RFID is used for quick
authentication at a long distance, which is why we chose it.
B. Car Detection
This sub block is the car detection block of our system. Our
parking meter needs to know when a car pulls into the parking
spot because not all the cars that park there are guaranteed to
have handicap placards thus we need to have some way of
detecting any car that pulls into our parking spot.
Inductive loops are one of the most widely used sensors in
modern traffic management systems [3]. Inductive loops are
simple but reliable sensors that can accurately detect when
large metal object drive over them. An inductive loop sensor is
comprised of 3 major components, a large loop of wire, a
circuit to detect the car and lead in cables from the loop to the
electronics box
Team 19 HP-ID MDR Report (DRAFT)
3
range can be changed even more by varying R1. R2 controls
the amplitude of the 555 output. This output is in parallel with
the LC tank circuit, this tank circuit is made up a capacitor
(C5) and the inductive loop (L1), this tank circuit has some
resonance frequency defined by
and at resonance
the LC circuit will have infinite impedance because the
impedance
of
a
tanks
circuit
is
defined
as
[6].
Figure 1 An illustration of an inductive loop sensor [5]
The idea of the inductive loop is simple. A large loop of
wire is embedded into the pavement. This loop of wire is
going to have some natural inductance and when a car drives
over the loop, the metal in the car will cause a change in
inductance and this change is detected by a circuit. The reason
for the change in inductance is because of the nature of
inductors. Inductance is determined by the number of loops of
wire and core of the inductor. When there is no car over the
loop the core of the inductor is air or asphalt, however when a
car pulls over the spot the iron of the vehicle will act like the
core of the inductor and result in a greater inductance.
However, when the car drives over the loop there will also be
eddy currents that are induced from the metal in the car as
well. These eddy currents will cause a decrease in the
inductance of the loop and will have a greater impact then the
effect of the iron core resulting in an overall decrease in
inductance [3].
The circuit that is used to detect the change in inductance is
simply a tuned circuit. The circuit will have a parallel LC
circuit, also called a tank circuit, that will be tuned to
resonance frequency and when the car cause the change in
inductance the circuit will detect that it is no longer at
resonance. Fig 2 shows the circuit diagram we will be using in
our car detector [9].
Fig 2 Schematic of the loop detector circuit
The left side of the circuit is an astable 555 timer, and
generates an oscillating voltage. The frequency of this
oscillation is set by the potentiometers and R1. The resistors
can be turned for an oscillation between 31 KHz-73 KHz, this
The series of resistors and capacitors after the tank circuit
rectifies the signal into a constant DC voltage, this voltage is
then input into the LM393. The LM393 is a voltage
comparator that outputs high when the voltage into pin 3 is
greater than pin 2. The voltage into pin 3 is fixed by a simple
voltage divider set by R5 and R8.If the input from the tank
circuit is higher than the voltage set by R5 and R8 then the
LM393 will be low and vice versa. When there is no car over
the loop the tank circuit is tuned for resonance so its voltage
output is maximum and greater than the voltage at pin 3.
When a vehicle change the inductance of the loop the voltage
at pin 2 will decrease because the new inductance will have a
different resonance frequency that the circuit is not tuned to.
Then the voltage at pin 3 will be greater than pin 2 and the
LM394 will output HIGH.
To test this circuit I will drive over the loop using several
different types of cars and note at which point on the car I get
the best detection. Compact cars will be easier to detect
because the body of the car is much lower to the ground. I will
test my inductive loop using a compact car, a mid-size SUV
and a Pickup truck. I will also test the circuit using different
loop shapes and sizes; I will use a circular loop radius 2 feet, a
rectangular loop and a square loop.
C. RFID (Radio Frequency Identification)
RFID is a form of wireless communication that uses the
radio frequency electromagnetic fields to transfer data. [1]
RFID stands for Radio Frequency Identification. RFID
technology is used to automatically identify objects or monitor
objects.[2] On top of automatically identifying objects, RFID
can be used to monitor the status of objects or simply track
them. In a RFID system there are three parts; the reader, the
transponder, and the antenna. The transponder is also called a
tag. The tag is usually a small chip and an antenna that sends
data to the reader.[1]
There are 3 types of tags: Passive, Active, and SemiPassive. Passive tags do not require a battery to send
information and have a built in antenna. Passive tags receive
all of their energy from the read/write device (reader) that
"powers" the tag to allow it to transmit data.[3] In a passive
system, the reader interrogates the tag and the tag responds
with its ID/information. Passive tags are generally much
smaller because they don’t require a battery. Passive highfrequency (HF, typically 13 MHz) and low-frequency (LF,
around 125 kHz) systems typically exhibit a read range of less
than 3 feet.[3] Passive tags (non-battery) typically have
anywhere from 64 bits to 1 kilobyte of non-volatile
memory.[3] Systems that use passive tags at a larger distance
require expense high powered readers. Passive tags are
Team 19 HP-ID MDR Report (DRAFT)
generally cheaper and have a much longer life expectancy.
Active and semi-passive RFID tags use internal batteries to
power their circuits. An active tag also uses its battery to
broadcast radio waves to a reader, whereas a semi-passive tag
relies on the reader to supply its power for broadcasting.[4]
The battery may be used to boost read/write range, allow for
larger memories, or add sensory and data logging capabilities,
such as temperature sensing.[3] Active tags are a “talk first
tag”. This means that the communication between the reader
and the tag must be initiated by the tag. In an active system,
the reader just listens until it receives a signal from a tag.
Active tags, such as those used in military tags, have
memories as high as 128 kilobytes.[3] Active and semipassive tags are reserved for costly items that are read over
greater distances -- they broadcast high frequencies from 850
to 950 MHz that can be read 100 feet.[4] Active tags require a
battery to be replaced and are generally more expensive.
Using RFID in our project will require a lot of
experimenting and familiarizing ourselves with this new
technology. We will have to learn about how the tags and
readers communicate with each other. We will also need to
learn how to integrate RFID into a micro-controller to allow
communication with the rest of our system. Our RFID block
consists of the handicap placard, reader, tag, and microcontroller. Since we want the tag to be linked to a person not a
car, the tag will be integrated into a handicap placard. A
handicap placard can be moved with a handicap person, as a
handicap person moves from car to car. The tag will have
button or some type of sensor that will tell the tag when to
send out its information to the reader, which will conserve
battery power. The reader and micro-controller will be inside
of a meter mounted in front of the handicap parking spot. The
reader will be connected to a micro-controller, which will
interpret the information and relay it to the other necessary
components. A car can pull into a parking spot nose in, or rear
in, so the tag will need to be able to communicate with the
reader over the distance of an entire parking spot (8 by 15
feet).We want the lifespan of the tag to be at least 2 years,
because we don’t want the tags to require replacement often.
After research and many phone calls to companies, we have
decided to use the Tagsense ZR-10 and ZT-50. We also
decided to use an Arduino Uno. The ZR-10 is a reader
powered by the Arduino Uno and the ZR-10 is an active tag
powered by a 220mAh coin cell battery. The ZR-10 and ZT50 have a communication distance of up to 100ft. This range
can be adjusted to conserve the battery in the ZT-50. The
battery life of the ZT-50 can be over 2 years if it is
programmed correctly. The active reader can be integrated
right into an Arduino Uno to allow for the information from
the ZT-50 to be processed. The ZR-10 has a baud rate of
57600. The Arduino Uno serves as the host for the reader. The
Arduino Uno can also be used to program the ZR-10 and ZT50. The ZT-50 and ZR-10 are 1 inch x 1 inch x.5 inch, so they
are small enough for our application. The only difference
between the ZR-10 and ZT-50 is that the ZT-50 is
programmed to “talk first”. The ZR-10 is programmed to
receive the tags information and relay it to the host (Arduino
Uno). Out of all of the readers and tag combinations out there,
this one is the best because it can be used at the prototyping
and design level.
4
Passive tags would not work in our case because of many
reasons. The use of passive tags at a distance of 15 ft., requires
a very expensive, high powered reader, which cannot easily be
integrated into a micro-controller for prototyping. These high
powered readers are very large and consume a large amount of
energy. Passive tags can easily be cloned because they don’t
have a built in micro-controller. One issue with the use of
RFID is the issue of tag cloning. Active tags are not as easily
cloned because each active tag requires a specific reader.
Active tags also have micro-controllers which allow the reader
and tag to use a communication algorithm to verify the
validity of the tag. Active tags can also be locked so that once
the settings are correct the information inside cannot be
changed or seen, except by a correctly programmed reader.
In order to build this block, we first need to ensure that the
tag and reader are functioning the way they are supposed to
out of the box. The factory setting for the ZT-50 is to transmit
its ID every second, once powered. The factory setting for the
reader is to relay the tag’s ID to the host every time it receives
a signal from the ZT-50. In order to test this function I connect
the reader serially to the computer via Arduino, I then power
the tag and see if the reader sends information to the
computer. The correct information was outputted so I know
the tags and readers are transmitting the proper data. I also
tested the communication at different distances to verify that
this tag and reader could communicate over the distance of an
entire parking spot. The table to the right shows the results.
As you can see, the ZT-50 and ZR-10 can communicate at
distances well over a typical handicap parking spot. We can
decrease the power of transmission to maximize the coin cell
battery life in the ZT-50. The next step in building this block
is integrating the ZR-10 with the Arduino Uno. We want the
Arduino Uno to be able to decipher the ZT-50’s ID and the
ZR-10’s ID from the ZR-10’s incoming data stream. We want
the Arduino Uno to be able to store both the ID’s so that the
information can be relayed to other blocks of the system.
We have foreseen many problems in the future and planned
Distance from Reader
Success Rate
2m
10 out of 10
4m
10 out of 10
6m
10 out of 10
8m
10 out of 10
10m
10 out of 10
12m
10 out of 10
accordingly. One potential problem that might arise is if a tag
from a neighboring spot tries to communicate with the reader.
This can be avoided because once a handicap placard is
validated in a parking spot the reader will not validate a
placard in a neighboring spot. This is done through the
database and pairing ZR-10 ID’s with ZT-50 ID’s. Another
potential problem is if someone steals a handicap member’s
placard. If someone steal’s a placard from someone else, the
Team 19 HP-ID MDR Report (DRAFT)
stolen placard will be marked stolen as soon as the original
owner tries to get a new placard.
David will be the main designer and assembler of the RFID
block. David will also use the information he learned in
Computer Systems Lab to program a micro-controller and use
it in a system. Fields and Waves will also be used in building
the physical container for the meter so it doesn’t interfere with
the radio signal. Circuits I and II will also play a role in wiring
the micro-controller and ZR-10 correctly.
ZT-50 and ZR-10
http://en.wikipedia.org/wiki/Rfid
http://www.technovelgy.com/ct/technology-article.asp
http://www.zebra.com/us/en/solutions/getting-started/rfidprinting-encoding/rfid-tag-characteristics.html
http://electronics.howstuffworks.com/gadgets/high-techgadgets/rfid3.htm
D. Microcontroller: Arduino Uno Rev 3 Board
This sub block is the micro-controller block, which will be
running a program to control the different components of the
project, namely the RFID reader, Wi- Fi Shield, inductive loop
and the database. We are using the Arduino platform to
control most of the components using an Arduino Uno
Revision 3 board. Arduino is an open source prototyping
platform, which uses an Arduino Programming language to
program and control an ATmega328 micro-controller board
[11]. This Arduino board is powered through a typical wall
outlet, a USB connection to a computer, or a battery. The
board can provide up to 5 Volts of power to the components
connected to it. The written program is uploaded to the
board’s 32 KB memory through the Arduino’s IDE via a USB
cable connection. [11]
For this block, we will use techniques learned in our
Computer Systems Lab along with software engineering class.
Computer Systems Lab provides a strong foundation for
programming micro-controllers while Software intensive
engineering provided training in programming using C++,
which is very similar to the Arduino Programming language.
In order to get this block to work, we need to learn the
proper usage of the Arduino Integrated Development
Environment (IDE) and its syntax. Getting familiar with the
different libraries is also an important part in order to be able
to approach the problem in more than one way.
Testing the system can be done by providing the microcontroller with RFID and induction loop inputs, then
5
analyzing how the micro-controller responds to these inputs.
We can have a good idea whether or not this component is
working properly by examining the outputs we receive.
E. Internet Connectivity to the Arduino board
This sub block provides the Arduino board with Internet
connectivity so that the Arduino can transmit and receive data
through a wireless network (Wi- Fi). This will be done by
mounting an Arduino Wi- Fi shield on top of the Arduino.
This shield enables the Arduino to connect to securely
encrypted (Access requires a password) or open Wi- Fi
networks.
Wi- Fi networks vary based on the encryption they use or
lack thereof. The Wi- Fi shield supports networks encrypted
using Wired Equivalent Privacy (WEP), Wi- Fi Protected
Access (WPA), and open (unprotected) networks, which is the
networks that we are most interested in. [11] WEP was
designed to provide the same level of security that a wired
network provides. WEP requires the user to input a password
to gain access to the network. [11] WPA is designed to
provide better security than WEP since it utilizes more
advanced encryption techniques [12] WEP’s weaknesses make
WPA the more secure option. We are mentioning WEP,
despite its weaknesses, in this report since the Arduino Wi- Fi
shield is capable of connecting to both WEP and WPA
secured networks. The Arduino Wi- Fi shield can detect the
networks available and their encryption types giving the user
enough information to decide which network to connect to.
The user then utilizes the appropriate program templates based
on the encryption type, which are provided as part of the WiFi library on the Arduino.
Concepts in encryption and wireless connection gained
from Trustworthy Computing class will prove to be very
helpful in the design of this block since we are dealing with
mostly encrypted networks.
In order to be able to design this component properly, we
need to know how to utilize the templates provided for the
Arduino Wi- Fi shield and adjust them appropriately for our
needs. It is essential to understand wireless networks to the
extent of being able to create a local one.
We originally planned on using the Umass Secure-1x WiFi network to connect our Arduino to the Internet. However,
after further investigation and testing, we came to the
realization that the Arduino Wi- Fi shield cannot connect to
the secure network. The reason for this being that the Umass
Secure-1x network utilizes WPA2 Enterprise encryption,
which is a very advanced encryption method that requires both
a username and a password for login compared to just a
password in WPA and WEP encrypted networks. The
complexity level of this encryption yielded the Arduino Wi- Fi
shield unable to connect to the network. We have attempted to
search for alternatives to allow us to connect to the network,
such as other Arduino Wi- Fi modules, but were unable to find
a shield that is able to handle such complex encryption. We
discussed this issue directly with personnel from the Office of
Information Technology (OIT) at Umass Amherst. They could
not find an alternative around the encryption level on the
network. OIT suggested setting up a local wireless network
through a laptop that is connected to the Umass network
instead. A local network can be set up to have an encryption
Team 19 HP-ID MDR Report (DRAFT)
level which the Arduino Wi- Fi shield can connect to. We
have also consulted with Prof. Ganz from the ECE department
and she suggested the same solution.
Thus for our connection to the Internet, we created a local
wireless network through a Macintosh laptop. The laptop is
connected to the Internet and can share the connection
wirelessly. We can then password protect the network using
one of the supported encryption methods. Using the Wi- Fi
shield, we can connect to this local network and gain access to
the Internet.
A useful experiment we can conduct is connecting the
Arduino to the Internet through a Wi- Fi connection that is
already set up. The Wi-Fi connection would utilize WPA
encryption, which is found in almost every household. We can
analyze the performance of the shield by observing the
number of successful connections compared to the total
number of attempts. We can also try sending data through the
shield to the Database component (which will be discussed in
a section to follow). The successful sending of data ensures a
connection to the Internet, which is the primary focus of this
component.
E. Base Station
Our Base station is a laptop that is on the same wireless
network as our Parking Meter. It consists of two major parts,
a MySQL server for the database and a PHP script to query
the database. The database stores all the important
information that needs to be known about the handicap parker,
such as their name, expiration date, and RFID Tag key. It also
has two fields where a placard can be marked as stolen or lost,
to prevent people from using placards that they shouldn’t be
using. There are also two fields (LastRead and Validity),
which are used as flags for our database query. The PHP
script is used to read and write to the database, and is used to
send out alerts to the authorities by email. There are three
main cases we need to deal with: a user with a valid Handicap
Placard, a user with an invalid Handicap Placard, and a user
that does not have a Handicap Placard at all.
When a car pulls into the spot that has a placard, the microcontroller in our parking meter will update the LastRead field
in the MySQL database that corresponds to that person’s
RFID Tag ID. When that Field is set to true, the PHP script
running on our Base Station will check the validity of that
parker by making sure their tag isn’t expired, or hasn’t been
flagged as lost or stolen. If the parker’s placard is valid then
the PHP script will set a person’s validity field to true, which
in turn will tell the micro-controller to enable a Green LED
which tells the person they are allowed to park there.
If the person’s card is not valid, and they are using a stolen,
lost, or expired placard, then their validity field would be set
to False. The micro-controller would then illuminate a Red
LED, which would tell the person they need to move within
the next 30 seconds or their car will be reported for misusing a
handicap spot. If the person does not move in 30 seconds then
an email alert would be sent out from our Base Station to the
authorities.
The final case that needs to be dealt with is if a person who
doesn’t have a placard at all and just parks their car in the
handicap spot. When a car a pulls into the spot, and our
micro-controller determines that it does not have RFID tag in
6
their car, a Red LED will be enabled just like the previous
case, and the person will have 30 seconds to move their car. If
the car isn’t moved in time then the micro-controller will write
to the database to a specially designated “anonymous” user
that will be used to tell the Base Station that it needs to send
an email to parking services.
Currently since all of our major components aren’t
integrated, to test these cases we are letting the PHP script run,
then manually querying the database. To test the first two
cases we will have one user with has a valid placard and then
another user that has an expired placard. Then we will
manually set the user’s LastRead value to true, which will then
let the PHP script do its processing. For user 1’s case it will
display a success message in the terminal, for users 2’s case it
will send out an email. To test the last case we will manually
set the anonymous LastRead field to true, which will then send
out the email.
Working on the Base Station is Andrew Baraby. He is
using skills he learned in Computer Systems Lab to help work
on the micro-controller, and also from Software Intensive
Engineering, which gave him good knowledge in Unix and
helped with programming the scripts.
III. PROJECT MANAGEMENT
Table II below lists our goals for MDR for our project.
Specification
Assigned To
Value
Mark
100
Internet Connectivity for
Microcontroller
Redwan
100
Configure Database and
Server
Andrew
100
RFID Tag and Reader
Communication
David
50
Car Detection
Inductive Loop
Using
Table II
Current Progress:
We currently have a system that has the following sub blocks
completed: Car detection is completed through the usage of
the inductive loop. Internet connectivity was established for
the Arduino using a local wireless network through a laptop,
which is connected to the Internet. The database, where all the
users information is stored in, was successfully completed
through a MySQL database. The RFID reader and tag are
communicating together, further work on this component is
being done.
Future Outlook:
As we can observe, the system’s sub blocks are awaiting
integration, which will be the objective of next semester’s
work. Some of the challenges ahead of us include developing
a specific procedure for what the system should do when an
illegal parker is discovered. Another challenge is to
differentiate between a car that is pulling into a parking spot to
actually park and a car that is merely pulling in to back up and
Team 19 HP-ID MDR Report (DRAFT)
turn around along with other possible scenarios. Another
example of an important challenge to tackle is the issue of
privacy and security for our RFID tags; in other words, we
need to ensure that our RFID transmissions are secure and
clone-proof.
For the Gnatt Chart, please see the attached document.
Team Expertise:
Although all team members have a similar educational
background gained from ECE curriculum, there are some
differences that made each team member focus on a specific
area of the project. For example, Mark and David’s experience
from some of the Electrical Engineering classes, sparked their
interest to focus on the hardware components of the project.
Classes such as Electronics II, Fields and Waves, and
Microwaves influenced their decision to use inductive loops
and RFID reader sub-systems.
Andrew and Redwan focused on the software side of the
project since they have more experience in that field from
being computer systems engineering majors and taking
courses, such as Software Intensive Engineering and
Computer Systems Lab 2.
The varying experiences complement the team well to achieve
the objectives at hand.
Team Communication:
Effective communication between team members is an
essential part of every project. We meet at least once a week
once per week in the SDP lab to discuss the current progress
and plans. We also meet with our advisor, Prof. McLaughlin,
once per week to provide him with updates on current status of
the project. Outside of the weekly meetings, the team
members communicate on a daily basis using group
messaging and email alerting the other members of the group
to any updates or changes. Andrew, David, and Mark also take
a class together, so they communicate after class at times and
then update Redwan if there is a change. This usage of
different communication methods, such as email and
messaging, ensured the most recent developments to be shared
between the team members. The team also constantly
provides ideas to each other for improvements on each other’s
components. We also utilized the Google Docs drive as a
collaborative tool to produce our presentation and reports
together, thus ensuring that everyone’s thoughts were included
in the creation of the presentation or report.
IV. CONCLUSION
For MDR we wanted to have each of our individual parts
working and we have successfully done that. Currently, we
have four major components of the project working
independently. The Basestation with its database and PHP
script are up and running. We have Wi- Fi connectivity
between our Arduino and the Internet. For our car sensor, we
have a working inductive loop. And finally, we have
communication between our RFID Tags and RFID reader.
The next major part we would like to have done is
communication between the Arduino and the Base Station’s
database via Wi- Fi. This is a huge part of the project and
once it gets done, it will allow us to really move forward and
7
start testing out our complete system with the RFID tags and
car sensor.
Once that is complete we can start fine-tuning our system
by testing it with some real life scenarios. For example the
time may need to be altered for how long the micro-controller
waits until a response is sent out to the authorities. We have
also discussed the potential of adding a camera to our system
which would allows us to take pictures of the violators and
have that be sent attached with the message alert to the
authorities.
Other minor things have been discussed, such as how many
LEDs are on the parking meter, how bright they are, and if the
meter make a sound when a violator needs to move. We are
going to work on these things last since they aren’t as
important. Our main focus right now is getting all of our
major components integrated together.
APPENDIX
ACKNOWLEDGMENT
We would like to thank our advisor Prof McLaughlin for all
of his support and resources.
REFERENCES
[1]Anderson, Karen. "Boston Drivers Caught Using Dead
People’s Disabled Parking Placards." CBS Boston. CBS
Boston, 21 Nov. 2013. Web.
[2]Brill, Linda. "Disabled Parking Fraud Costs Seattle $1.4
Million a Year." KING King5.com. King 5 News, 10 June
2013. Web.
[3]"Chapter 2, Traffic Detector Handbook: Third Edition—
Volume I." Chapter 2, Traffic Detector Handbook: Third
Edition—Volume I. U.S Department of Transportation Federal
Highway Administration, May 2006. Web.
[4]"Disabled Parking FAQ's for Customers." Disabled
Parking FAQ's for Customers. Massachusetts RMV, 2013.
Web.
[5]Gibson, David. "Staying in the Loop: The Search for
Improved Reliability of Traffic Sensing Systems Through
Smart Test Instruments." Public Roads. US Department of
Transportation Federal Highway Administration, Oct. 1998.
Web.
[6]"LC Circuit." Wikipedia. Wikimedia Foundation, 23 Nov.
2013. Web.
[7]Peter, Justin. "Handicapped-Parking Fraud Is Just About
the Jerkiest Crime Imaginable." Slate Magazine. Slate, 27
Aug. 2013. Web.
[8]Shannon, Jeff. "The Parking Placard Glut." New Mobility
RSS. N.p., 1 Sept. 2008. Web.
[9]"A Simple Vehicle Loop Detector." Vehicle Loop Detector.
Chemelec, 12 Oct. 2008. Web.
Team 19 HP-ID MDR Report (DRAFT)
[10]Tierney, Anna. A STUDY ON WHY PEOPLE ABUSE
HANDICAPPED PARKING. University of Wisconsin-Stout
Graduate School, Mar. 2002. Web.
[11] Arduino Uno Rev 3 (Online). Available:
http://store.arduino.cc/ww/index.php?main_page=product_inf
o&cPath=11_12&products_id=195
[12] Jennifer Johnson WEP (Online). Available:
http://palmtops.about.com/od/glossary/g/WEP.htm
[12] Bradley Mitchell WPA- Wi-Fi Protected Access (Online).
Available: http://palmtops.about.com/od/glossary/g/WEP.htm
8