Asset Control System

Carley Baltromitis, Casey Quinn, Kenneth

Sullivan, and Daniel Williams

Dept. of Electrical Engineering and Computer

Science, University of Central Florida, Orlando,

Florida, 32816-2450

Abstract — Over the years there have been many improvements in allowing the use of certain equipment to authorized users only. This however was inhibited by the integration at the system level. Thus arises the problem of cross-over portability to other devices that companies would want to control access or log use with. This paper will discuss the use of modern technology to provide a scalable general use asset control system.

Index Terms — Asset Control, Radio frequency Identification, Power Relay, Web Services, Embedded System.

I. INTRODUCTION

All of the members in Group 3 Spring/Summer 2016

wished to not only fulfill the requirements needed in

Senior Design, but also wished to build and design

something that would have needed use outside of the

school. The idea for a generalized asset control device

came from an idea from Dr. Reza Abdolvand, who

wished to have such a system for laboratory use. While

meeting with him, the scope of his idea was a bit outside

the means of Senior Design. Still intrigued with the idea

of creating a device that would allow authorized user

access and furthermore track use with the potential for

invoicing, Group 5 met with Dr. Richie and got the green

light to go with our scaled design idea for a general asset

control device that would allow for direct power control to

any standard wall mounting equipment. This task would

be accomplished using an embedded system in an

accessible and relatively small kiosk for every device

under control. The kiosk would be networked into

constant communication with a database that would allow

for holding authorized user lists and the logging of time

in/ time out at each kiosk for the user. The main method

of permitting access would be using a RFID scanner, with

having a default username/ password setup as a backup.

The kiosk interface will also feature a LCD touch screen

which will be utilized for feed back as well as

administrative purposes. Due to the fact that Group 5 is

self-funded we hope to achieve our goal for the least

amount, which leaves us finding the best option for the

most affordable price, giving the end user a system that

will be unbeatable for performance versus cost.

II. SPECIFICATIONS

The following are the design specifications for the

Asset Control System:

1) Wireless communication between device and system

will use RFID.

2) The system will not occupy a space larger than

8x8x5 in3

3) The system will record and provide user history.

4) The system will provide feedback to user on status.

5) The system will control the power to specified

devices up to 12 Amps at 120 Volts

6) The kiosk power use will be 3 Amps (max)

III. SYSTEM COMPONENTS AND DESIGN

A. System Overview

The Asset Control System is made of two main

components the remotely located database and the kiosk

located next to the equipment which would like to be

controlled. The database will be a standard PC based

server that will be connected to a wireless router. The

kiosk will consist of 2 main processing units the ATmega

328 microcontroller and the Raspberry Pi SoC. The

ATmega will be controlling the relay and reading data

from a current sensor, while the Raspberry Pi will be

reading data from the RFID scanner, touch screen, and

then communicating wirelessly to the server, as well as

embedded communication to the ATmega. The whole

kiosk will only run on outlet power, due to the equipment

being controlled by the kiosk. A brief system overview is

seen in Figure 1

Figure 1. Asset Control System

B. Kiosk Design

The kiosk device will be relative small and light

weight. It will securely house all components, which

include the LCD touch screen, RFID scanner, Raspberry

Pi, current sensor, relay, and ATmega PCB. The kiosk

will be able to moved and placed on any level surface and

could be plugged into an extension cord if needed. The

only cables that would be externally visible from the kiosk

case will be the power cable into the kiosk and the power

cable to power the equipment. Due to the nature of our

product it is crucial that these connections are housed

inside of the kiosk housing so that no bypassing can be

created without purposeful intent. The kiosk case will be

designed in Solidworks and 3D printed to match our

specifications needed.

C. ATmega

The microcontroller chosen for the kiosk in the Asset

Control System is the ATmega328. This MCU was

chosen due to the cost, available features of the pins, and

the vast support available online. For the current sensor

we will be taking advantage of the available analog pins,

and the relay will use one of the many other digital

communication pins. The use of an external 16 MHz

clock will also be used. The low power functionality of

this AVR based MCU, will also be useful as it will only

draw 100mA at absolute max power. The small footprint

of the TQFP package, as seen in Figure 2, is also crucial

as we want the kiosk to occupy as minimal space as

possible.

Figure 2. Size comparison of ATmega TQFP package

D. Relay

After much debate and research into ways to control

power from accessing equipment, a standard relay was

chosen as the right device. Other choices were determined

to be not highly rated enough to handle the voltage and

current, or it required manipulation of the source power

signal, which might ultimately cause a malfunction with

the equipment we are controlling access to. The latching

relay has a rated coil voltage of 5 Volts and the contacts

are rated for 240 Volts at 30 Amps. This will meet our

requirements and it also provides back EMF protection

with a diode.

E. Current Sensor

The current sensor is connected to the voltage line from

the relay. This sensor is connected to the ATmega’s

Analog to Digital Conversion pin. From this pin we will

be able to take in the reading and pass them onto the

Raspberry pi to display on the LCD touch screen to show

the amount of current being used by the equipment being

powered. The current sensor that the kiosk will use is the

ACS712, due to the wide variety of currents that our

kiosk device might see it was decided to not incorporate

this sensor on the PCB design. Using this form of the

sensor it was still crucial that it have a small footprint, as

seen on Figure 3, this form does have that.

Figure 3. Size of the ACS712 sensor.

F. Raspberry Pi

The Raspberry Pi 3 utilizes a Broadcom BCM2837

SoC, with a CPU capable of 1.2GHz quad-core. The form

factor, like the rest of the Raspberry Pi series the form

factor is relatively small, about the size of a credit card.

The major key factor in determining this as the

Embedded PC was that this version of the Raspberry Pi

came with Wi-Fi capability already built in. This is a

huge help as it will reduce the cost of getting an adapter

and reduces the need to route more wires to the database.

It allows for Windows 10 IoT to be run, which offers not

only a familiar development environment, but also a

familiar environment for the user. It also offers 1 GB of

RAM which is more than enough for the needs of the

kiosk in the Asset Control System.

G. LCD Touch screen

The LCD touch screen is a key component of the Asset

Control System kiosk sub-system. This component allows

for direct interfacing with the kiosk and networked

interfacing with the database. It will also be a key source

for back up if the RFID Scanner malfunctions for any

reason, the user will be able to use a username and

password procedure, using the on screen keyboard. The

LCD touch screen that will be used with the kiosk is the

official Raspberry Pi touch screen, which connects

directly to the embedded computer and is directly

compatible as far as known working drivers. This touch

screen also requires fewer connections and has more

support in the form of troubleshooting and accessories.

H. User Interface

The user interface will be fundamental in structure as

the kiosk needs to be straight forward and use and require

no training to use. It will be able to provide the user with

direct feedback and real-time results of current use. It will

offer the user anytime to pause their session or end and

logout. A flow chart of the user interface is shown in

Figure 4.

Figure 4. UI Flowchart

I. RFID Scanner

The RFID scanner that will be implemented in the asset

control system is the RC522. This scanner is a relatively

simplistic one with a decent range of 50 mm, which

should be enough even behind our plastic enclosure. The

scanner will work on 2.5 to 3.3 Volts and operates on less

than 100 mAmps, which will be supplied by the

Raspberry Pi. The information will be given from the

RFID scanner via on ASCII string through a serial

output. The small form factor as seen in Figure 5, is also

an ideal feature for the Asset Control System, as it will

keep the overall footprint of our kiosk down.

Figure 5. RC522 RFID Scanner

J. Embedded Communication

The ATmega328 will need to stay in communication

with the embedded computer, to update the system on

status and also receive the code to activate the relay from

the Raspberry Pi. There are several ways in which the

raspberry pi can communicate with the microcontroller,

though the only way that will be able to reduce the need

for extra components and least number of connections is

the I2C protocol of communication. This communication

style will be explained more in the next section, but the

overall basics is that it features a master and slave

component setup, that utilizes two lines to transmit

scripts to give the commands of, turning the relay off,

turning the relay on, status of device, and the up to date

value of the current being used by the device.

K. I2C Communication

The I2C communication protocol is the method that

will be used between the embedded Raspberry Pi and the

ATmega328 microcontroller. I2C is a serial single-ended

computer bus that was invented by the Philips

semiconductor division. The idea behind the choice was

to incorporate a simple two-way serial connection. The

Raspberry Pi, which will be programmed as the master,

will be able to send byte sized commands to the

ATmega328 microcontroller, which will be programmed

as the slave. The microcontroller will also be able to send

data back in response to commands given by the

Raspberry Pi. The use cases for communication between

the embedded computer and the microcontroller include

turning the relay on, turning the relay off, asking current

relay status, and asking for up to date current use. A more

complete table of the code that will be passed and the

action to be taken by the ATmega328 microcontroller can

be seen in Table 1.

Code ATmega328 Action

1 Turn Relay On

2 Turn Relay Off

3 Give current relay status

4 Give up to date current

measurement

Table 1. Embedded use states

L. Power

The Asset Control System kiosk will be powered by 120

Volts AC from a wall outlet. This AC power signal when

then will be transferred to a 12 Volt DC converter. For

this task a Mean Well 12 Volt, 50 Watt, DC power

converter will be used. This will take in the source power

and convert it into a useful DC signal. This power supply

has a small footprint of 4x4x1 inches as well as a

protective and heat transferring shell that will make sure

no further damage will come to the case or our

equipment.

From the Mean Well DC power converter the original

designed printed circuit board will take in the power. And

it will be handed over to two different linear regulators.

The linear regulators were chosen over switching

regulators for their small size, lower noise level, and

overall less complex circuit design, thus using fewer parts

with less points of failure. Both regulators are rated for 5

Volt output, however, one will be a low noise linear

voltage regulator that will provide power to the

ATmega328 microcontroller. The Microcontroller we

would want to have low noise as it will be handling both

analog and digital signal and would not want noise being

in the circuit allowing for read errors. The other 5 Volt

linear regulator is at a higher rated current level, which is

3 Amps. This 5 volt power supply is intended to provide

power to the Raspberry Pi 3, which has a max power

consumption at 2.5 Amps. This will allow for more

possible use of this regulator as a source of power if

needed, though the low noise regulator provides a max

current of 500 mAmps, which is more than enough for

the ATmega328 microcontroller.

The ATmega328 microcontroller, when receiving the

appropriate code from the Raspberry Pi, will switch on

the relay. The relay will have source power 120 V AC

connected to it from the input point of the Mean Well DC

converter. The following Figure 6 is the multisim

simulation showing how rapid the switching of power

access is, as well as how the original power signal is in no

way changed or interrupted.

Figure 6. Multisim simulation of relay circuit

The simulation also was able to show how much

voltage it would take to create the required source voltage

out. From these data points the ability to tell when and

how much power would be used by the relay is easily see

from the graph in Figure 7. This graph show relay coil

voltage versus the contact voltage of the relay, this is

indeed a good proof of concept to show why the relay is

an ideal option for the place of the switch.

Figure 7. Voltage of coil versus power of Coil and Load

The overall power routing and control is the most

essential task of the Asset Control System. The goal to

transform power has to be done with the most care to the

system, which is why the back EMF protection to the rest

of the circuit including the printed circuit board and

Mean Well power supply. Figure 8 shows the overall

cimplified block diagram for the power routing.

Figure 8. Simplified power block diagram

IV. SOFTWARE DETAIL

Ultimately, the coding plan solely depends on the

features implemented in the physical device, because the

best practice when it comes to software is to use the

correct tool for the job. In this case, the tool refers to the

programming language for each application. Normally,

on a target computer such as the Raspberry Pi, the

preferred programming language is C or Python since the

preferred operating system is a distribution of Linux.

This would only affect the Asset Control Device because

the remaining of the complete system would communicate

via HTTP commands (sometimes referred to as web

services calls, web API calls, or REST service). This is

essential for the main server architecture to be

independent of the clients’ architecture.

However, adding more sophisticated authentication

features, such as the facial recognition would require

much extra planning and programming to be successful

given the project’s slim timeline. Utilizing Windows 10

IOT and its facial recognition SDK could drastically

reduce the development time. After researching more

into the Windows 10 IOT Core, it would allow a common

language codebase for the Asset Control Device since

device-driver like functionality is already present within

and would not require a group member to tackle these

tasks. This is also beneficial to the Graphical User

Interface (GUI) because it would also fall within this

common codebase because all Windows 10 IOT

applications are referred to Universal Windows Platform

(UWP), which are written in any .NET language that

utilizes the Common Language Runtime (CLR) such as

C#, VB.NET, F#, etc, but most commonly written in C#.

Another benefit of using Windows 10 IOT is the built in

device drivers for the popular Raspberry Pi WIFI cards

and the Raspberry Pi official touch screen.

Since human interaction is one of the primary

requirements of the project, the Asset Control Device

application shall be written first, at least in the capacity

that will allow interaction with the authentication devices

that will be chosen for the final project build. This part of

the complete system should be written first because it is

the first interaction point with the user, therefore, it is

essential that all features work as planned. Once the

initial proof of concept is working that validates correct

functionality of the authentication methods, the

intermediate service layer can begin its development

process. Since all data passed between the clients and

server will be using the HTTP transport layer, the

architectures of the clients will not be dependent of the

server and vise versa. Therefore, the server can be hosted

in any environment. It is more common to see a linux

based server rather than a Windows based server, and

hosting price may vary with architecture also. As long as

the server and client utilize a central interface, the

development process can occur concurrently with the

GUI. Figure 9 is a representation of how our final coding

plan should be with regards to REST service calls.

Figure 9. REST system coding plan

In considering the operating system with which to run

the system we are creating we should consider two factors

of importance to us. The first factor is that the cost of the

operating system needs to be as low as possible. In the

case of Linux this is the cheapest option available since it

is essential open software. Basically there is no need to

purchase a license. With windows both IOT and 10

require a license. However IOT is not typical of Microsoft

windows operating systems. It is downloadable without

purchasing a license unlike windows 10. The operating

system windows IOT envelops the abilities we need to

address and communicate with multiple devices. IOT

does not provide a true graphic interface like normal

windows. It does however offer the ability to store data

and utilize com ports which will be an important part of

this project. The system does not need a graphic user

interface within it. Instead we will use remote accessing

techniques to configure and test the database

functionality. The operating system requirements include

the ability to use com ports and the ability to send

information to remote devices. Another requirement will

be security. The operating system will need to be secure

and require security protocols that will protect the

integrity of the system from unauthorized access. The

system will hold a database and process commands and

queries from the remote interfaces. A block diagram of

the server architecture is seen below in the following

Figure 10.

Figure 10. Main Server Architecture coding plan

The devices for asset control will require a wireless

interface that will receive activation or deactivation

commands from the system. The devices will be

equipped with a touch screen display that provides user

feedback to the screen for actions taken. This means that

the devices will send an authorization request and then

display data on usage and status. The operating system

will need to facilitate the requests and provide

information to the devices about time and transaction

data. The devices will also provide updates to the

database for the individual events that occur. In order to

facilitate this the system will need to track each device in

real time. This will allow for any change in status to be

detected and then subsequently to update the database

accordingly. It is imperative that the system keeps a log of

every instance and its corresponding user data since this

is one of the primary goals of the system. The scheme

and table for the database is found in the following Figure

11.

Figure 11. Scheme and tables for database coding

For user interface we will design an application that

can be accessed via website or through a mobile app. The

testing of the user interface will be done using a standard

pc with an operating system that current and viable. This

operating system can be any flavor. We can use any

operating system that is compatible with a well known or

utilized web browser. The goal is to design the system to

meet the html standards of all major web browsers. With

the browser compatibility in mind we will ensure through

testing that it is functioning within the requirements of

the system. Since the system acts remotely and accesses

the database the testing environment for the interface side

will be a windows based pc and an android application.

The testing of the software on each platform will be based

on the user case associated with the platform. For

instance the administrator level will be accessible through

a web browser. The user level interface will be accessible

through web browser or mobile application.

V. PCB DESIGN AND FABRICATION

An essential part of the senior design project is the

process of identifying parts and connecting them all in a

circuit to create a unique circuit board that fits the needs

of the project. For this the group used EagleCAD to align

all circuit elements in the Asset Control System, this

simplistic part of the PCB design process is shown in

Figure 12.

Figure 12. PCB EagleCAD schematic of Asset Control System

Once all circuits were identified and connected in the

schematic they have to placed in a circuit board

configuration. The board the group wishes to make only a

simplistic 2-layer board that has a relatively small

footprint. The routing on the board required care and

patience. The trace widths are important to watch when

dealing with higher currents, which is why on the 3 Amp

output coming from the voltage regulator there is a wider

trace, this can be seen on the Figure 13. Also present on

this Figure, is a technique the group decided to use,

which is called a ground pour. This eliminates the need to

run countless ground traces which might highly

complicate the circuit.

Figure 13: PCB EagleCAD Board

The group then decided to have the board sent to OSH

park to fabricate the board. Using the Super Swift service

they offer, we were able to get the 2-layer board printed

for $5 per sq. in. Since the board for the group is only

3.25x2.25 inches, it cost under $40 for them to be made.

The group did encounter some last minute changes to the

board which ended up in some added routing which was

achieved before the boards were made. Once the

components were obtained from Digi-Key and Mouser the

boards were completed as shown in Figure 14.

Figure 14: Completed Asset Control System PCB

VI. CONCLUSION

Group 5 has encountered several problems in Senior

Design. However, due to constant dedication and

collaboration within the group, we have been able to

continue meeting deadlines and milestones. With most of

the hardware already created and the software nearly

complete, Group 5 is on track for completing a working

demonstration on time. Microcontroller development,

database and UI development, power routing & control,

PCB design, and system integration All experiences we

will add to our resume in hopes of having a great

foundation, with which to develop our future careers in

the field of engineering.

VII. ACKNOWLEDGEMENT

Group 5 of the Spring and Summer 2016 Senior Design

class would like to acknowledge and thank the faculty and

staff of the Department of Electrical Engineering and

Computer Science at the University of Central Florida for

all their support and guidance.

VIII. THE TEAM

Carley Baltromitis is a senior

at the University of Central

Florida. She is graduating

with her Bachelor’s of Science

in Computer Engineering in

August of 2016. After

graduation she will be

employed as a VB.NET

programmer with the website,

OnlineLabels.com, which she

had an internship with.

Casey Quinn is a senior at the

University of Central Florida.

He is graduating with his

Bachelor’s of Science in

Electrical Engineering in

August of 2016. He has

recently accepted a position

with United Launch Alliance

in Cape Canaveral as a systems

test and maintenance engineer.

Kenneth Sullivan is a senior at

the University of Central

Florida. He is graduating with

his Bachelor’s of Science in

Computer Engineering in

August of 2016. He has been

working at Rockwell Collins in

Melbourne as a software

engineer intern and now as a

test engineer.

Dan Williams is a senior at the

University of Central Florida.

He is graduating with his

Bachelor’s of Science in

Computer Engineering in

August of 2016. He has worked

in IT field for many years and

would like to expand into

software or hardware

engineering after graduation.

IX. REFERENCES

[1] Commercial Asset Control Device <http://www.euchner-usa.com/key.asp> [2] Mean Well Power Supply <http://www.jameco.comPWg> [3] MOSFET and BJT Comparison <http://www.completepowerelectronics.com/comparison-of- mosfet-with- bjt/> [4] SCR and Relay Comparison <https://ghadzhigeorgiev.wordpress.com/2011/08/24/netduino-tutorial- replacing-relay-with- scr/> [5] Pin-out for Raspberry Pi <http://pinout.xyz/pinout/spi> [6] Raspberry Pi and Arduino Connection <https://oscarliang.com/raspberry-pi-and-arduino-connected-serial-gpio/> [7] Advantages and Disadvantages of Linear Regulators <http://www.digikey.com/en/articles/techzone/2012/may/understanding-the-advantages-and-disadvantages-of-linear-regulators> [8] Using Eagle <https://learn.sparkfun.com/tutorials/using-eagle-board-layout> [9] Using the ATmegaXXX Microcontroller <http://upvector.com/atmega/> [10] Using Arduino Bootloader <https://learn.sparkfun.com/tutorials/installing-an-arduino-bootloader/connecting-the-programmer> [11] jQuery API <http://api.jquery.com> [12] Grove 30A Relay <http://www.seeedstudio.com/wiki/Grove-SPDT_Relay(30A)>