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