# Industrial IoT Monitoring: Technologies and Architecture Proposal
## 5 Proof-of-Concept
### Results
The latency generated by adding the monitoring mechanisms to the sensor nodes firmware, as well as the microcontroller's memory taken by the monitoring mechanisms are also two relevant aspects in assessing a monitoring solution. The firmware graphs, in Figure 4c,d, show the number of cycles executed by the microcontroller in three firmware functions, and the RAM and ROM requirements, respectively, with and without monitoring. In terms of processing overhead, the manual instrumentation performed in the code of each function inserts an average of 758 cycles (\(\sigma\) = 3 cycles), adding 93 \(\upmu\)s of latency at 8 Mhz clock. As can be seen in (c), the overhead is quite small, when compared to the cycles spent to execute the functions without monitoring, representing 5.1%, 1.2%, and 2.2%, for functions 1, 2, and 3, respectively. This test was performed manually, by measuring the difference of cycles at the beginning and at the end of the instrumentation functions, using the Code Composer and the MSP-FET. An analysis in terms of memory was also made, measuring the increase of flash memory and RAM. In what concerns flash memory, the main application without monitoring occupies 18.590 KB, as represented in Figure 4d. Adding the sensor node monitoring agent and the instrumentation code, the application size increases to 34.659 KB. This represents an increase of 12.26% of the total capacity of the flash memory in this microcontroller version (131.072 KB). Lastly, as also presented in Figure 4d, the main application without monitoring takes 1.631 KB of RAM. Adding the sensor node monitoring agent to the application increased RAM usage to 2.506 KB. When compared to the initial utilization, the sensor node monitoring agent only consumes an additional 8.54% of all the RAM available in the microcontroller (10.240 KB). The network overhead caused by the sensor node monitoring agent was also measured. Using health reports collected every fifty minutes by the gateway monitoring agent, we were capable of measuring the traffic generated by a leaf node in normal operation and with the monitoring capabilities enabled. As can be seen in Figure 4e, the main application sends 76 packets/hour (\(\sigma\) = 0 packets) on average. Most of this traffic is generated by the publish service that sends the temperate values every minute. Enabling the sensor node monitoring agent causes a traffic increase of 46%, sending an average of 165 packets per hour (\(\sigma\) = 9 packets), of which 89 packets are generated by the sensor node monitoring agent. In WirelessHART, the IEEE802.15.4 payload is limited to 94 bytes per packet. Thus, each packet sent by the sensor node monitoring agent is capable of carrying six log entries, each with log id, function id, function duration, processing metric, and energy metric. Summing up, the assessment of the proposed monitoring architecture, carried out through this proof-of-concept implementation, shows its low impact and high efficiency in what concerns sensor node resources and network. Table 5 summarises the obtained results. By causing a mere 3.5% reduction in sensor nodes' battery lifetime, introducing a 93 \(\upmu\)s latency overhead in each function, occupying 12.26% of flash memory, and using 8.54% of RAM, the implementation enabled the monitoring of hardware and firmware in sensor nodes. Despite the increase of 46% in network traffic generated by sensor nodes, the proposed solution, here implemented for WirelessHART, used network resources in a smart way. The monitoring data was only sent when the network had resources to send it, requesting the service and deleting it each time the sensor node monitoring agent needed to send monitoring data. Using this approach, the sensor node monitoring agent only requested free network resources, not used by the main industrial application.