PTC Security Team

California University of Pennsylvania

Fall 2014 CET 490 Software EngineeringDecember 11, 2014

Instructor Comments/Evaluation

1

Table of ContentsTABLE OF FIGURES--------------------------------------------------------------------------------------------------- 2

Abstract---------------------------------------------------------------------------------------------------------------- 3

Description of the Document-------------------------------------------------------------------------------------4

Purpose and Use---------------------------------------------------------------------------------------------------------------4

Intended Audience------------------------------------------------------------------------------------------------------------4

Project Block Diagram with Description-----------------------------------------------------------------------5

Design Details--------------------------------------------------------------------------------------------------------- 5

System Modules and responsibilities------------------------------------------------------------------------------------6Architectural Diagram-------------------------------------------------------------------------------------------------------------------6Module Cohesion-------------------------------------------------------------------------------------------------------------------------6Module Coupling-------------------------------------------------------------------------------------------------------------------------7

Design Organization-----------------------------------------------------------------------------------------------------------7Functional Description------------------------------------------------------------------------------------------------------------------8

Input/output/return parameters/types-----------------------------------------------------------------------------------------8Modules used--------------------------------------------------------------------------------------------------------------------------9Files Accessed------------------------------------------------------------------------------------------------------------------------11Real-Time Requirements----------------------------------------------------------------------------------------------------------12

Decision: Programming language/Reuse/Portability--------------------------------------------------------------------------13

Implementation Timeline--------------------------------------------------------------------------------------------------14

Design Testing-----------------------------------------------------------------------------------------------------------------14

Appendix: Team Details------------------------------------------------------------------------------------------16

Appendix: Workflow Authentication--------------------------------------------------------------------------17

2

TABLE OF FIGURESFigure 1 Block Diagram------------------------------------------------------------------------------------------------------------------------5Figure 2 Architectural Diagram--------------------------------------------------------------------------------------------------------------6

3

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 DocumentPurpose 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.

4

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.

5

Figure 1 Block Diagram

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.

6

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

7

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.

Functional Description

8

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

alerts they receive from the system.

9

Modules used

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.

10

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.

11

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-Time Requirements

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.

12

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

13

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.

14

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.

15

“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.

16

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.

Appendix: Workflow Authentication

I, Isidro Garcia, confirm that I have performed the work documented herein.

17

 

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:                                            

18