IoT Layout
IoT setup was similar to all other three cases, even if devices were in fact connected to
different LANs, all of them were logically connected to the IoT server hosted in the control
room LAN.
As before, all IoT devices shared the same username and password credentials. Due to
network design in this Cisco Packet Tracer exercise, only the PCs connected to the con-
trol room LAN could access to the IoT homepage.
72
Figure 53 - IoT connected device homepage
As illustrated in the Figure 53, Smart-industrial exercise had several IoT devices already
configured such as: solar panel, wind turbines, batteries, motion detector, webcam, AC
unit, temperature sensor and an IoT smart-light.
For the solar panels, wind turbines and batteries, located in the land and sea network,
no backend intelligence was required as only an IoT cable was needed in order to con-
nect the power generators to the batteries.
Clear instructions how to connect IoT device input and output slots were listed in the
device specification tab. As visible in the Figure 54 the output port of the solar panel is
D0 and the input of the battery is D0, cable was then connected accordingly.
Figure 54 - Example of battery specifications
73
As quickly mentioned, for this scenario, no backend logic is implemented, however from
the main IoT page was still possible to monitor in real time the amount of power gener-
ated by the units and the amount of electricity stored by the batteries.
For future expansion additional logic conditions can be added in order to raise alarms if
the battery stored power would drop below a certain threshold. Also a power meter could
be installed between the turbine and the batteries in order to visually show the amount
of electricity produced.
As solar and wind electricity generation was directly proportioned to the solar rays and
wind gusts, the relative environmental variables were modified.
As visible in the Figure 55 below, two separate containers have been created and vari-
ables have been manipulated in order to generate wind and sun during the day. Sunlight
variable does not necessary need to be changed as by default over the daytime hours
the simulator will produce sunlight.
Figure 55 - Environmental variables
As demonstrated in the Figure 56 below, while observing the environment clock, it was
very evident to see the peak time of solar electricity production.
74
Figure 56 - Electricity production peaking during the daytime
It was also observed that, even without any device connected to the battery draining its
power, there was a constant battery discharge happening by default.
As previously mentioned the IoT server was hosted in the IoT control network.
Server, as in the other IoT simulations, used static IPs also acted as DNS server trans-
lating the iotcontrolpage.com address in its own IP address.
Along with the server also an IoT surveillance solution example was connected to the
IoT control network. This case simulated a security system, running in the power plant
control room that, when motion was detected, automatically started a webcam broadcast
for few second.
This IoT automation could be triggered via pressing ALT on the keyboard and hoovering
the mouse on the motion detector. While connected to iotcontrolpage.com via browser it
was also possible to see the changing of the webcam icon showing some images frame.
Once no movements were detected the webcam automatically stopped.
75
Figure 57 - Example of webcam broadcasting when motion detector is triggered
The other IoT simulation samples were for devices connected to the IoT industrial net-
work such as: an intelligent lamp, and automatic AC unit with a thermometer, a motor
and potentiometer.
As explained earlier the intelligent lamp did not required any backend intelligent being a
very smart device on its own, unit had in fact embedded a motion and a light sensor,
making the lamp itself able to decide to lid in case of object are detected or if it is late in
the day and no sunlight is visible. The lamp was included in the Cisco Packet Tracer
example in order to show also the possibility to connect devices to an IoT battery in order
to drain its power. As illustrate in the Figure 58 below a special IoT cable was used to
connect the two units, port specifications were available in the device specification tab.
76
Figure 58 - Example of complex specifications for the smart-lamp
The other standard IoT simulation in this example, that required backend logic, auto-
mated a machine room temperature monitoring system. For this purpose a smart tem-
perature meter and an AC unit were connected to the IoT industrial WLAN. Additional
backend logic was set to automatically start the AC unit when a temperature below 35
degrees was detected. By design, and in order to make students practice with them, no
environmental variables of the engine room physical container were modified, this re-
sulted in the temperature being constantly under the 35 degrees threshold, hence the
AC did not start. It is advisable that students will manipulate the variables in order to
validate the logic of the rule.
Temperature and AC status could be monitored by connecting to the IoT homepage.
77
Figure 59 - AC and temperature monitoring from IoT homepage
The last IoT simulation in the exercise was the only non-smart device example, without
using microcontrollers, provided in any of the four exercise.
This case was utilized to show to the students that even without microcontrollers, or IoT
backend connection, it is possible to utilize IoT actuators and sensors, however with very
limited capabilities.
In this case a knob potentiometer was connected to an industrial motor, motor was then
draining power of one IoT battery from the land network. As in previous applications a
special IoT cable was required between the units.
Interaction with the motor was also possible by pressing ALT on the keyboard and mov-
ing the knob clockwise with the mouse. Motor rotations increased by rotating the knob.
However, as far as the knob and the motor were not connected to the backend IoT
server, it was not possible to observe or control them from the iotcontrolpage.com page.
Figure 60 - Knob rotation impact the motor speed
Cisco Packet Tracer offered also the possibility to transform sensors and actuators in
smart devices by double-clicking on the device, selecting the advance button, adding
then a wireless card in the I/O config tab and then setting up SSID and password in the
config tab.
78
Once done the devices were visible in the main IoT page, however, as the control APIs
were missing there was no possibility to check the status or setup further functioning
conditions.
| 