4.4 Limitations and Expansions of the IoT Simulations
The four IoT simulations offered a solid foundation for the students to experience the
Internet of Things without having the access to physical IoT devices or IoT network. Ex-
ercises also offered the possibility to expand the simulation even further. However, due
to limitation of the tool and due to time-constraint, some aspect of the exercise were
simplified or artificially created.
In all the Packet Tracer examples where an ISP was required, there was no real ISP
component in the tool, hence the network was made up using routers and static IPs. In
the second smart h
ome exercise, where backend capabilities were provided “as-a-ser-
vice”, the home router was also artificially setup to use default gateway IP of the IoT
cloud server. This would not have been possible in a real case.
The other examples of artificial setups were in the Smart-Campus and Smart-Industrial,
where some IoT device were in fact connected via a switch using normal straight copper
cables. This setup would not be practical in real scenarios due to the distance limitation
of the LAN connectivity over copper.
The other limitations, or one could call them as bugs, are due to general behavior of
Cisco Packet Tracer tool itself. Even though the tool seemed to be more stable compared
to the earlier version, it tended to crash or not functioning properly every now and then.
When making the simulations, but also during the class, the network components were
not always correctly communicating between each other even if the setup was correctly
made.
Other problematic cases happened when the IoT Smart-device configuration was
changed few times, in some of these cases the IoT device did not connect to the backend
IoT server anymore.
In all of these examples the suggestion given to the students was to erase the compo-
nents and restart the configuration by adding new device. This in most of the cases
solved the issues.
Other known issues were related to the malfunctioning of the custom program running
on the IoT smart devices. The program seems to run, but logic did not work, as happened
with the RFID reader program.
81
The students were advised to stop and restart manually the application in the device
programming tab, as shown in the below figure, every time the Cisco Packet Tracer was
launched the first time.
Figure 62 - Example of custom Phyton program running on RFID reader device
Another limitation observed during the course, not related to Cisco Packet Tracer but
more on the structure of the classes, was related the limited amount time reserved for
the IoT practical part in the study course.
Being the first time this course had been taught, and the fact that the structure of the
classes had been decided before a deeper analysis of Cisco Packet Tracer complexity
was completed, it resulted in underestimating the time necessary to be reserved for the
practical classes.
82
Other smaller limitations came from the fact that all students should have created their
own Cisco NetAcad account beforehand and also have the Cisco Packet Tracer installed
in their own laptop.
As mentioned earlier, despite the limitations caused by the tool or the time, the simula-
tions had been built beforehand allowing students, with different skillset, to adapt their
own IoT business case or even further expand them, both on network and IoT level.
As previously listed in the chapter 4.3 future expansion of the simulations are possible.
Regarding the network area students could, in the two Smart-home cases, upgrade the
VPN connectivity in order to be able to remotely access the home LAN when connecting
from an external network. Another example is to add a firewall in order to limit the access
to the IoT network from the remote office LAN in the Smart-industrial case. In Smart-
Campus the IoT network could be re-organized by using a cellular infrastructure.
IoT smart-devices expansion should be also very simple for the student, purpose would
be to add more devices within the IoT network and create more intelligent rules via the
IoT backend server. In some of the case this would require also that IoT network would
be expanded in order to be capable in running more devices.
Last and more technical expansion could be the usage of microcontroller. Multi-Chip
Units (MCU) or Single-Board Computer (SBC) can be widely used in the simulations in
order to fully control the IoT device functions. IoT server backend intelligence, program-
able via browser, it is only possible for smart-devices and only allows simple IF-THEN-
ELSE rules. Programming of microcontroller instead offers full visibility on sensor param-
eters, actuator functions, data logging and also allows to use a wider range of IoT de-
vices.
Microcontrollers should also be connected to the local IoT network.
Students with stronger programming skills, were encouraged not only to program
MCU/SBC board but also modify or create the pre-set program of the sensor and actua-
tors, giving full freedom and control of the IoT device.
|
