Detailed descriptions of our progress through the project can be
found here.
A door security system which allows the home owner to interact
with the visitor and other home members regardless of the owner's
location.
It is frustrating when people drop by when one isn't in the
house. Instead, any time visitors drop by, the home owner can see
who is there, can interact with them through video or text
messages.
| Product\Features |
Price |
Door lock/unlock feature |
Card access to home |
Alert other members when one enters home |
Alerts owner when visitor comes by. |
Video chat/messaging with visitor |
| DoorBot |
$190 |
x |
x |
x |
✓ | ✓ |
| Lockitron |
$150 |
✓ | x |
x |
x |
x |
| SmartDoor |
$150 |
✓ | ✓ | ✓ | ✓ | ✓ |
Architecture:
R-1. When the doorbell is pressed, the tablet display shall turn
on with the message, "Taking a picture to send to OwnerX. Would
you like to proceed?".
R-2. When the visitor chooses to take a picture, the tablet shall
take the picture of the visitor using the embedded camera, and
forward the picture to the owner's phone.
R-3. If at any time the visitor chooses the "Leave" menu on the
tablet, the display shall show the message, "Thank you, Goodbye".
R-4. The display shall turn off if there has been no input for 30
seconds.
R-5. After the picture has been sent, the tablet shall load the
menu for the visitor with the options for video-chat, text
messaging, or "leave".
R-6. Selecting the video-chat option shall send a Skype call to
the owner's phone. (Constraint: Owner's phone shall have a camera
attached).
R-7. Selecting the text-messaging option shall load a virtual
keyboard on the tablet, ask the visitor for the message, and
forward the message to the owner.
R-8. Owners of the house shall be able to unlock their door by
their personal RFID keychain.
R-9. Owners of the house shall also be able to unlock their door
by inputting a preset password into the electronic deadbolt.
| Risks |
Mitigation Strategy |
| Deadbolt is not responsive to the Arduino |
Revert to original mode of operation for the
deadbolt-requires manual input. |
| Tablet bluetooth is unresponsive to the
Arduino |
Switch protocol to WiFi and try again. |
| Camera on the tablet fails to turn on when
required |
Load text input interface on the tablet
instead of video chat for the visitor to leave a message. |
| Tablet theft |
Make it built into the door. |
| Arduino fails to recognize RFID keychain |
Revert to manual mode for deadbolt. |
Test Cases:
| Test |
Why do they matter? |
How to run the test? |
| Simultaneous injection of doorbell press and video call. (fault-free) | We don't want the video call to be interrupted unless the visitor/owner desires it. | User executes the two tasks simultaneously. |
| Fault Injection: Door fails to unlock with RFID. Check if it unlocks manually, and if the system recognizes it has been unlocked. | We don't want to be stuck in a state where the system is constantly ordering the door to unlock without success. | Have a specific RFID key which the system
will approve of, but not open the door (program a separate
case for this key). |
| Bluetooth test (fault-free) |
We want to ensure a reliable connection
between our systems. |
Connect to the BT module from the Android
application and verify the BT connection. |
| Bluetooth test (fault-injected) ` |
Same as above |
Send garbage value instead of protocol for
doorbell acknowledgement. |
| Doorbell test (fault-free) |
It must be read for the Android application
to load. |
Verify that the input is read and the tablet
loads the welcome message accordingly. |
| Camera test (fault-free) | Picture must be taken when visitor requests
it. |
Verify that the camera loads when the camera
button on the app is pressed and successfully takes a
picture, and saves it to the SDCard on the tablet. |
| Email test (fault-free) | The picture must be sent to the owner. |
Verify the email is sent with the correct
photo attachment. |
| RFID deadbolt test (fault-free) | It must be correctly read to grant home
access. |
Verify that upon scanning it on the reader,
the door unlocks. |
| RFID deadbolt test (fault-injected) | Same as above |
Program a specific key which will fail to
unlock the door. Verify that the program does not get stuck
waiting for the door to unlock. |
| Manual deadbolt test (fault-free) | Door must unlock when the correct pass code
is input. |
Verify that upon inputting the correct pass
code, the door unlocks. |
| Video call test (fault-free) | Visitors must be able to video chat with the
owner when they wish. |
Verify that upon choosing video chat on app,
it sends a video call request to the owner's mobile device. |
| Display test (fault-free) | Power saving |
Verify the tablet display turns off after 30
seconds. |
| Application exit test (fault-free) | Correct "shut-down" of app |
Verify that when the visitor chooses the
leave menu, the tablet loads up the goodbye message. |
Experimental Evaluation:
| Experiment |
Metrics |
Why do they matter? |
How to measure the metrics |
| Bluetooth Communication Throughput |
Throughput- Maximum characters that can be
sent in a message. |
Ensure the application does not crash because
too many characters have been sent. |
Test with different message sizes |
| Doorbell response time |
Latency from doorbell press to tablet welcome
message |
Noticeable delays in between
acknowledging the doorbell input and loading the appropriate
tablet display is undesirable. |
Stopwatch |
| RFID response time |
Latency from RFID read to door unlock |
Waiting too long for the door to open after
the RFID chip is read is also undesirable. |
Stopwatch |
| Android app lag time |
Latency from photo request to loading the
camera on the tablet |
We want the application to be as lag-free as
possible. |
Stopwatch |
Graphs expected: pdf after repeatedly measuring each of these metrics. Box/whisker plot.
Reproducibility of tests: Time/environmental settings will be
kept the same to ensure reliability of repeated measurements.
Automation of tests: For the first experiment, we will add a
short snippet of code to our Arduino code to repeatedly send
messages of random size, rather than our protocol for
acknowledging a doorbell press. For the rest, we will embed a
timer in the code to check the timing every time our program is
run.
To be completed by the end of Spring 2013 semester.