IoT Layout
As in the previous IoT automations all the smart devices were remotely connected to the
IoT server sharing the same username and password credentials. Connection also was
established by using the static IP of the IoT server hosted in the same IoT network.
As per design and, due to network layout and utilization of RIP protocol, every PC, laptop
and smartphone connected in any of the campus network could remotely access to the
IoT homepage URL. The IoT server, being also DNS server, translated the homepage
URL into its own static IP.
When connected to the IoT homepage via browser, and after successfully passing the
authentication, IoT users were able to see the list of connected devices and the interac-
tion logic between them.
Figure 42 - IoT connected devices in Smart-Campus simulation
62
As displayed in the above Figure 42, in this Cisco Packet Tracer exercise four IoT de-
vices were connected: RFID reader, apartments door, water monitoring sensor and sport
field sprinkler.
Also visible in the Figure 43 is the logic assigned to these four devices
Figure 43 - Pre-set IoT conditions
The first automation was aiming to create an IoT RFID access control solution for man-
aging the access in the students apartments using a RFID reader, couple of RFID cards
and a smart door.
The concept behind was very simple, when an authorized RFID card was swiped onto
the RFID reader the door opened, but if an unauthorized RFID card was utilized the door
remained locked. In order to achieve such scenario the RFID card parameters were
modified by editing the card attribute tab as shown in the Figure 44 below.
63
Figure 44 - RFID card attribute modification
In this cases two cards were utilized, one with value 3535 and the other one with 1212.
As illustrated in the Figure 43 the authorization logic was done in the IoT backend server,
as the condition was set to unlock the door when the 3535 was swapped.
Swapping the card was done simply by dragging the card on the RFID reader using the
mouse. Green icon appearing in the reader meant that card was authorized, at the same
time also door icon turned from red to green. If wrong card, with value 1212 in the exam-
ple, was utilized, the reader icon stayed red along with the locked door icon as visible in
the Figure 46.
Figure 45 - Valid card swapped on the reader Figure 46 - Invalid card swapped on the reader
64
For this specific case, and only because of the logic how the reader worked, a third
waiting condition was set. Reader in fact stayed in a waiting loop, ready to accept new
card, till any card was placed on it. While reader was in this loop the smart-door remained
locked.
The specifications of how the reader worked and all the expected status were clearly
explained in the device specification tab.
In this scenario the smart-door was utilized as device that reacted to conditions however,
due to its versatility, the device could be used in more complex simulations. Direct inter-
action of the door was also possible by pressing ALT in the keyboard and clicking the
door icon.
The RFID simulation was only created with the main purpose to show different IoT sce-
narios to the students. It was however clear that, in more complex applications, utilizing
the IoT backend logic was not the best option, as far different combinations of cards and
access level were impossible to achieve with simple conditions.
Another consideration to mention is that, in Cisco Packet Tracer, the RFID reader did
not always perform properly. When launching the simulation for the first time, the reader
did not accept any card. Students were adviced to always stop and restart the reader
internal program when launching the exercise for the first time. This was done by clicking
on the device, then on the advance button and last on the Programming tab, once there
it was possible to stop and start again the program as shown in the Figure 47 below.
Figure 47 - Stopping a device program
The second IoT case in this exercise simulated a smart sport field irrigation system,
where a sensor detected the level of water and, in case lever was low, started the water
sprinklers. Logic can be seen in Figure 43.
65
In order to make the automation more realistic the environmental variable of the sport
field containers were changed to simulate raining through some hours during the day.
Figure 48
– Environmental variables for Smart-Campus simulation
As visible in the above Figure 48 rainfall were set to be happening between 03.00 and
06.00 and between 20.00 and 23.00 every day. Rainfalls increased the water level in the
sport field container, causing the water sensor to detect a higher amount of water and
not starting the sprinklers.
The below Figure 49 illustrates the sprinkler action when level of water was below or
above three centimeters.
Figure 49 - Smart-sprinkler running and not running
The field water absorption speed could also be boosted by adjusting sunlight and tem-
perature in the environmental variables.
|
