This design document outlines the details and requirements for a security management prototype project called FaciliteEZ. The project aims to reduce the cost of security systems from $7,000 per door to $700 per door. The prototype will use a Raspberry Pi module and RFID scanner to track the location of personnel and status of doors based on RFID card access. The document describes the system modules, architectural diagram, functional requirements, implementation timeline, and testing plan to ensure the prototype meets the needs of the intended users.

1. FACILITEEZ APPLICATION
Design Document
PTC Security Team
California University of Pennsylvania
Fall 2014 CET 490 Software Engineering
December 11, 2014

2. 1
Instructor Comments/Evaluation

3. 2
Table of Contents
TABLE OF FIGURES--------------------------------------------------------------------------------------------------3
Abstract ---------------------------------------------------------------------------------------------------------------4
Description of the Document ------------------------------------------------------------------------------------4
Purpose and Use--------------------------------------------------------------------------------------------------- 4
Intended Audience ------------------------------------------------------------------------------------------------ 5
Project Block Diagram with Description ----------------------------------------------------------------------5
Design Details -------------------------------------------------------------------------------------------------------6
System Modules and responsibilities--------------------------------------------------------------------------- 6
Architectural Diagram---------------------------------------------------------------------------------------------------------------------6
Module Cohesion---------------------------------------------------------------------------------------------------------------------------7
Module Coupling ---------------------------------------------------------------------------------------------------------------------------7
Design Organization----------------------------------------------------------------------------------------------- 7
Functional Description--------------------------------------------------------------------------------------------------------------------9
Input/output/return parameters/types ------------------------------------------------------------------------------------------9
Modules used--------------------------------------------------------------------------------------------------------------------------10
Files Accessed -------------------------------------------------------------------------------------------------------------------------11
Real-Time Requirements -----------------------------------------------------------------------------------------------------------12
Decision: Programming language/Reuse/Portability---------------------------------------------------------------------------13
Implementation Timeline ---------------------------------------------------------------------------------------14
Design Testing-----------------------------------------------------------------------------------------------------14
Appendix: Team Details----------------------------------------------------------------------------------------- 17
Appendix: Workflow Authentication------------------------------------------------------------------------- 18

4. 3
TABLE OF FIGURES
Figure 1 Block Diagram --------------------------------------------------------------------------------------------------------------------------5
Figure 2 Architectural Diagram ----------------------------------------------------------------------------------------------------------------6

5. 4
Abstract
Our project is trying to make the cost of Security Management decrease by ten times. It is
one half of the FaciliteEZ project presented by PTC. On average, security companies are
charging $7,000/door for a security management component. FaciliteEZ is attempting to reduce
that price down to $700/door. A security management component can include location of
personnel, who is where at what time, along with door status and RFID (radio frequency
identification) management. The component can determine if a door is opened or closed and
whether someone has access to the room with their RFID card. This document provides the
details and design needed to have a successful working prototype. The prototype would consist
of a Raspberry Pi Module B and an RFID scanner.
Description of the Document
Purpose and Use
The purpose of this document is to layout a clear and detailed explanation of each aspect
of this project. When provided with this document, the end user will be able to determine if this
project was able to meet all of their needs or not. Additionally, it will aid the designers in
ascertaining the requirements that must be met upon completion of the project as set by the end
user. The final purpose of this document will be used for is to stand place as a makeshift
checklist. As stated above, details of requirements are laid out by the client and included within
this document. As such, the designers are able to make sure that each of the requirements are
fulfilled.

6. 5
Intended Audience
This document was created with both the designers and also the users in mind. We used
this document to make sure that all of our clients need have been met. The client will have the
ability to carefully read over this document before design has begun to make sure that all their
needs are met if not exceeded. The designers have been helped by allowing a complete list of all
the components that will be required as well as how the devices will communicate with each
other. The designer will also be able to read over the document after the product is nearing
completion to make sure that all the client’s needs have been met.
Project Block Diagram with Description
Figure 1 shows the block diagram of the security side of our project. The user has one
way of communication and that is through the physical sensor, or in this case, the RFID scanner.
The Java Edge SDK will be mapping directly to our ThingWorx Remote Thing.
Figure 1 Block Diagram

7. 6
Design Details
Listed below we will have a description of all the system modules and responsibilities. Which
include with the architectural diagram, module cohesion and module coupling. All of these parts
are the primary components for our software. We can follow each one of these models to
properly implement our code and have a successful working prototype. The end goal is that the
user can access the ThingWorx from his office or from home if he is working from home.
System Modules and responsibilities
Architectural Diagram
Figure 2 Architectural Diagram
The application can be broken down into two access points, local access or full access.
Local access will be used more for managers or supervisors who only have access to one
building. Security levels will be granted to each user so if you only have access to your
buildings’ security level that will be the only view you will get.
On the other hand there is full access, more for owners or corporate. If you need to check
on all the building at the same time then this will be available in this mode of the application. It
will display all the workers in all of the building.

8. 7
Module Cohesion
These components use a procedural cohesion. Once someone scans their card then the entire
system goes into a process and assuring that that person has access to that specific room. Along
with the situation where a door is left open, if the timer is broken which means the door was not
closed in a certain amount of time then the system again goes into a process and checks what
time of day it is so it knows what kind of message to send.
Module Coupling
These modules are data coupled. Once the information is received in one, then it is passed on to
the other to verify or deny access. Then that module returns that information to the first module
so it can either allow the user access or deny the user access.
Design Organization
As our group is working on a security project for PTC, we will have to implement both hardware
and software into our design to accomplish all of our clients needs. To restate, the following
needs must be met in order to consider our project successful:
 A functioning Raspberry Pi Module B
 Software loaded onto the module
o This will enable communication between the RFID Scanner and the Raspberry Pi
 A functioning RFID Scanner
 Application software containing a(n)
o Login Page

9. 8
o Admin Page
 Complete with multiple tabs including:
 Time management within the security system
 Text fields to enter contact information for alerts
 A running log of each RFID card scanned
 RFID card(s)
o Each of which is unique for any individual employed by the organization
 A lock on each door of which the system is (to be) installed
The application that is to be created as a result of this project will be written in an IDE
(integrated development environment) provided by our client, and the data that will be obtained
from the working module will be stored on a server hosted through ThingWorx. The software
that is to be developed throughout the duration of this project is the larger aspect of the two that
must be accomplished. The complexity of the hardware does is at a lower level than that of the
software, so the design and development phases for this will be relatively short by comparison.
With a group comprised of four Computer Engineering Technology (CET) students, we have the
background and the required knowledge to test and configure this project in both aspects.

10. 9
Functional Description
Input/output/return parameters/types
With our project, FaciliteEZ will be able to provide a cost efficient security system to
businesses. By providing a functioning system of keycard readers that are activated by scanning
a RFID card provided by the user. The administrator of the system can configure clearances with
each door that will make use of this device. This will give them the ability to control what
personnel within the organization have the permissions to enter particular rooms of the facility.
Also, when each RFID card is scanned, the unique user data (ie. username, door entered,
timestamps, etc.) is to be saved and stored into a database hosted through ThingWorx. Using this
data, the administrator of the system will be able to identify the location of the various members
of personnel allowing them to ensure that they are in their correct location, accomplishing the
tasks that they have be assigned to do. Each system also must also track the amount of time that
the door on which it is installed is open. After a particular threshold in time is exceeded, an alert
message is to be sent to the administrator to notify them of this action via email. Finally, the
system must also notify the system administrator when there are any doors that are opened
during non-business hours.
In real time, data must be transferred, evaluated, and returned to the unit mounted on the
door within seconds, to allow access to the room that it is sealing. This means that the unit must
be powered at all times. In addition, the server must remain active at all times so that the
information that controls the permissions and restrictions set upon each employee can be
accessed. Also, said activity will also be required to send any alert messages to the administrator
of the system so that they may take appropriate action depending on which one of the various

11. 10
alerts they receive from the system.
Modulesused
There will be a few modules that will be used. There is the standard user module, an
administrator module, and a location module. Each module will have a specific function that
must be followed for their particular action to be completed.
For the standard user, they must scan their RFID card on the RFID scanner. Their data is
sent to the server and a response is returned. The server will then log the instance and update
files accordingly such as the current location file for the individual that scanned the card. The log
files for the time of the scan, and will scan the authorization file before it responds to the RFID
request.
The administrator module is to control all the administrative functions such as monitoring
the doors in a live mode. The administrator is able to open both the log file and the current
location file. When the admin opens the log files, they are able to see when a door was opened,
who opened it, how long it has been opened, and where all the employees are at any moment in
time.
For the location module it updates the files when a specific action is taken. The location
module will update the log file by changing when the most recent door was opened, who opened
it, what time it was opened, and how long the door remained opened. It will then also update the
current location file by removing the old instance of the person and overwriting it with their new
location and what time they arrived at the current location.

12. 11
There is a monitor module which will monitor all the doors. If a door is opened without
authorization it will send an alert to the proper people. If a door remains open after a certain
amount of time has passed, it will also send an alert to the request person. This module will
monitor doors 100% of the time.
Finally there is an alert module whose only job is to generate an alert based on what
another module will send to it. If it receives an alert for a door being open then it will generate an
appropriate alert based upon that. The alert will then be sent to the email or cell phone number
that was on file.
Files Accessed
There will not be that many files that will be accessed. A few that will be accessed will be the
log file, the current location file, and the authorization file. Each file will hold specific data to a
specific function within the program. Each will be accessed, read, processes will be done, and
the file with close.
The log file will keep track of what times all doors were opened last, the person who
opened the door, and how long the door was opened for. This file will be opened for two
functions; one would be to log the data, the other would be when the Thingworx application is
open and the admins have the ability to see who has opened what doors and when. This file is to
remain untouched for any other operation unless the client would wish to clear the file if the file
is getting to massive.

13. 12
The current location file only has 1 specific function. It will log the last location that an
employee scans their RFID card on a door. This will allow an effective “tracking” method. The
last location that they scanned their card is where they should be at the current time.
Unfortunately this is not 100% accurate as employees are not required to scan their card to leave
a specific area. Along with the location it will also log the time to which the employee scanned
their RFID card. This file will only be accessed by 2 processes. One process being the actual
logging of the instance, the other would be when an admin needs to see where all employees are
at a specific time. This file is “alive” in the way that it is always changing. If an employee
changes rooms, it will overwrite the old location showing their new current location.
Finally there is an authorization file which will hold all the RFID values for all
employees. This file will be accessed every time an RFID card is read at a door. It will check the
value that is read with respect to this file and if a match is found, the person will be able to enter
the specific room. The file will only be able to be modified by an administrator who is setting up
what rooms employees have access to.
Real-TimeRequirements
For the real-time requirements, there will be many functions that can operate at real-time speed.
Some of the functions would be the authorization process when an individual scans their RFID
card at any of the RFID scanners at each door. When an administrator logs in they must also be
able to see a “live” view of where everyone is at currently. Alerts must also be done as they
need. This must all be done real time or within a few seconds of when they should be going off.

14. 13
When an employee scans their RFID card almost instantly the scanner must send the data
to the server, receive either a positive acknowledgement or a negative acknowledgement and
from that decide whether or not to open the door. This must be done in a manner that doesn’t
slow down the daily routine as everyone has places to be. If they have to wait for the doors, then
it takes time that they could be using productively in turn reducing profits by increasing time.
When an administrator logs in to view where everyone is, it should be almost
instantaneous also. If it’s a few minutes late, one of the employees can be in an entirely different
area if they were looking for them. This can increase how long it takes an employer to find one
of their employees if they are not where they are to be.
When alerts are generated they MUST be in real time. If an alarm is activated at night the
sooner a police response can get there, the more of a chance the criminal could be caught. If an
alert is generate for a door being not properly closed, it too must be answered as quick as
possible as it’ll reduce the chance that an unauthorized person access an area where they should
not be.
Decision: Programming language/Reuse/Portability
The primary language that will be used will be C. Other parts of the overall application will be
written in an application called Thingworx. By using these options compared to other choices, it
will ensure that the application can be run on many machines. Being able to port the program to
multiple browsers will allow the system admins to monitor from anywhere, such as on the go on
smartphones, web browsers, or through other applications. Being able to access from multiple

15. 14
types of machines will increase the security of the building as a person wouldn’t have to waste
time being able to access the alert that was generated. The alert could be viewed on their mobile
phone allowing authorities to be notified if that is the proper action based on the alert.
We will be working with another group that will be providing the temperature monitoring
of the building. As such we will be reusing their login sections of code to maintain consistency
when logging into the server. The two groups will be working together for this section to make
sure authentication is done the same way for both sections. Reusing code together will also allow
the work load on each group to be reduced.
Implementation Timeline
Design Testing
FaciliteEZ will undergo very thorough testing to make sure optimal operation will be achieved.
Every section will have to be tested such as the worker tracking, door status responses, proper
alerts, and proper flexibility to be able to be modified.
Tracking will be tested in such a manner that many different RFID cards will go through
an obstacle course testing the results every couple minutes to make sure it is accurate. Expected
results would be current location of multiple people going through the maze. When they arrived
at the current section, and who was the last person to go through that area. If expected results are
recorded, testing can continue on a new section.

16. 15
Door status will be tested by first closing the door and monitoring if any issues occur.
The door will then be opened by one of the RFID cards. Expected results would be the person
who opened the door be logged in the main database, the time that the door was opened and the
person entered, and finally if the door is properly closed. If the door does not close correctly, an
alert should be generated and sent to the proper person to make sure the situation could be
resolved. An “after hours” alert should also be generated if any of the doors are opened when the
building is supposed to be unoccupied.
FaciliteEZ must also be able to be modified relatively easily. If the client requests more
doors to be added to the application, then it should be relatively easy to add more doors without
having to change the entire structure of the application. Modification of the alert methods must
also be relatively easy to change. If the person would no longer like to receive e-mails but would
rather receive a text message to their cellular device, then it should be easy to change. The plan
for this would just be a text box with either a cell phone or e-mail address to insert. Alerts should
also be able to be sent to multiple people rather than 1 specific person. There should be a team of
people who should be able to receive proper notifications for all alerts that are generated.
Some of the alerts that should be generated would be door open alerts, “after hour” alerts,
inappropriate entry alerts, or any other alerts that the client would wish to receive. The door open
alert would be generated if the door is open for a specified amount of time without closing.

17. 16
“After hour” alert would be if the door opened when the building is supposed to be unoccupied.
Inappropriate entry would be if a person who was not supposed to enter an area did or if a door
was opened with brute force without any type of authentication.
FaciliteEZ will also have to be coded to work appropriately on many browser types.
Everyone in today’s world does not stick with internet explorer, as such; the panel should be able
to be accessed on Google Chrome, Mozilla Firefox, Internet Explorer, and Safari as these are the
most common internet browsers today. If an administrator would have a browser that was not
supported, many problems would arise which could cost the company money. Not all browsers
will be supported, but the main ones will be.

18. 17
Appendix: Team Details
The leader for the Design Document for PTC Security was Isidro Garcia. He maintained
contact with each member of the team, assigned sections for each member, and set deadlines so
the final, revised document would be turned in error-free by the deadline set. Isidro also
constructed the Title Page, Table of Contents, and System Modules and responsibilities,
Architectrual Diagram, Module Cohesion, and Module Coupling. Devin Dill was in charge of the
design testing, real-time requirements, module design and proper functionality. This includes the
input/output of all data that would be used, Files that would be accessed, and proper alert
generation. O’Shea Browner did the design organization and Description. Erin Beaver did not
take part in the completion of this paper. Every member contributed to proofreading and double
checking the document. With the combined efforts of the team members, the document was
completed to the best knowledge of the team.

19. 18
Appendix: Workflow Authentication
I, Isidro Garcia, confirm that I have performed the work documented herein.
Signature: Date:
I, Devin Dill, confirm that I have performed the work documented herein.
Signature: Date:
I, O’Shea Browner, confirm that I have performed the work documented herein.
Signature: Date:
I, Erin Beaver, confirm that I have performed the work documented herein.
Signature: Date: