## 4 Generation of Benign IoT/IIoT Datasets
### Benign \"Powertrace\" Dataset Generation  
#### 4.1.1 Benign \"Powertrace\" Dataset Generation  
The \"powertrace\" dataset includes information about features such as total CPU energy consumption and low power mode (LPM) energy consumption. In fact, it is the dataset of the simulated benign IIoT network scenario that includes records about information related to the energy consumption of the IIoT devices (i.e., motes) deployed within the simulated IIoT network. To enable the \"powertrace\" plugin and generate the \"powertrace\" dataset, we programmed the motes of the benign IIoT network to make use of the \"powertrace\" plugin for collecting \"powertrace\" related features every 2 s. In particular, we included the \"powertrace.h\" library into the code of each mote (i.e., #include \"powertrace.h\"), as shown in Figure 4, and defined to start powertracing, once every 2 s, in the code of each mote as shown in Figure 5.  
Figure 4: “powertrace.h” library in the mote code. Figure 5: Powertracing Begin. Figure 3: Cooja Simulator—motes’ outputs. More precisely, the \"powertrace\" plugin captured raw information, every 2 s, about the set of features summarised in Table 1. In particular, the \"powertrace\" plugin tracks the duration (i.e., number of cpu ticks) of activities of a more being in each power state. Particularly, the outputs demonstrate the fraction of time in which a more remains for a given power state. There are the following six power states: (i) cpu; (ii) lpm; (iii) transmit; (iv) listen; (v) idle_transmit; and (vi) idle_listen, as shown in Table 1. These are measured with a hardware timer (i.e., clock frequency is defined in RTIMER_SECOND or 32,768 Hz for XM1000). In Figure 6, the depicted Mote output window displays the captured \"powertrace\" information every 2 s and also the messages sent and received by each note (printouts/printf messages from each note). Figure 6: Cooja Simulator—Mote output window. \begin{table}
\begin{tabular}{c c c} \hline \hline
**Index** & **Feature** & **Description** \\ \hline
1 & sim time & simulation time \\ \hline
2 & clock\_time() & clock time (i.e.,by default, 128 ticks/second) \\ \hline
3 & ID & Note ID \\ \hline
4 & P & label \\ \hline
5 & rimeaddr & rime address \\ \hline
6 & seqno & sequence number \\ \hline
7 & all\_cpu & accumulated CPU energy consumption \\ \hline
8 & all\_lpm & accumulated Low Power Mode energy consumption \\ \hline
9 & all\_transmit & accumulated transmission energy consumption \\ \hline
10 & all\_listen & accumulated listen energy consumption \\ \hline
11 & all\_idle\_transmit & accumulated idle transmission energy consumption \\ \hline
12 & all\_idle\_listen & accumulated idle listen energy consumption \\ \hline
13 & cpu & CPU energy consumption for this cycle \\ \hline
14 & lpm & LPM energy consumption for this cycle \\ \hline
15 & transmit & transmission energy consumption for this cycle \\ \hline
16 & listen & listen energy consumption for this cycle \\ \hline
17 & idle\_transmit & idle transmission energy consumption for this cycle \\ \hline
18 & idle\_listen & idle listen energy consumption for this cycle \\ \hline \hline \end{tabular}
\end{table} 
Table 1: “powertrace” plugin—Set of Captured Features. Furthermore, the Simulation script editor, shown in Figure 7, is a Cooja tool used to display messages and set a timer on the simulation. As shown in Figure 7, the upper part of the Simulation script editor was used to create scripts and the lower part to show the captured \"powertrace\" information and the printouts (i.e., printf messages) from the motes until the timeout occurs. In our implementation, we considered the simulation duration to be 60 min and thus, the timeout was set at 3,600,000 ms. When the timeout occurred, the simulation stopped, and all the captured information and prints were stored in the log file named \"COOJA.testlog\".