ViTool-BC: Visualization Tool Based on Cooja Simulator for WSN

: Evaluation and monitoring of wireless sensor networks (WSN) and the parameters deﬁning their operations and design, such as energy consumption, latency, and stability, is a complex task due to interaction with real devices. For greater control of these variables, the use of simulators arises as an alternative. Cooja is a WSN simulator/emulator which handles the devices’ controllers and multiple communication protocol implementations, such as RPL (RPL is one of the most used protocol in IoT). However, Cooja does not consider either the implementation of an energy model (it has inﬁnite energy consumption) nor the visual behavior of the topology construction, although these aspects are crucial for effective network analysis and decision taking. This paper presents the design and the implementation of ViTool-BC, a software built on top of Cooja, which allows the creation of different energy estimation models and also to visualize in real time the behavior of WSN topology construction. In addition, ViTool-BC offers a heat map of energy consumption traces. Therefore, this tool helps researchers to monitor in real time the topology construction, node disconnection, and battery depletion, aspects to be considered in the analysis of the available routing protocols in Cooja.


Introduction
Wireless sensor networks (WSN) are a type of IoT technology that is applied in multiple areas [1,2]. This field describes the communication of sensors distributed in areas of interest for collecting, monitoring, analyzing, and predicting environmental or external phenomena that affect the mentioned area. The applications of sensor networks include air quality aspects [3], disaster prediction [4], monitoring agriculture areas [5,6], and smart cities [7,8], among others. These sensors have many restrictions, from low energy and processing capacity to unstable connections between devices. Consequently, how the information is collected and retransmitted, considering the limitations, will determine the efficiency of the designed topology. For handling these restrictions and controlling the connections of the nodes of a wireless sensor network, several routing protocols are defined [9]. These protocols include rules and steps that govern the communication between the nodes, allowing them to optimize the use of these devices' resources.
The multiple applications of the WSN require the delimitation of communication protocols, topologies of the network, and physical specifications that adapt to the scenarios of interest. Therefore, it is necessary to understand the theoretical definitions of these protocols and topologies, which allow us to correct the problems and specific phenomena in these scenarios. Given the difficulty of assembling and controlling a testbed of physical sensors [10], simulators emerge as an alternative for validating operations of a WSN with their parameters. The use of simulators on IoT into the deployed WSN helps with the measurement and estimation of the metrics, allowing the evaluation of the performance and quality of service (QoS) of a designed network or its topology control [11,12]. Some of these used metrics in WSN include energy consumption, latency, bandwidth, stability, and network lifetime, among others [13]. Also on Cloud computing, these metrics extend

Related Works
Multiple tools and simulators have been defined and developed to emulate the behavior and remotely visualize connections of a network topology [17,18]. These simulators require extensive knowledge and hours of handling them for the deployment of test scenarios. OPNET Simulator [19] is defined as a tool for WSN simulation, and the behavior of any network, including sensor networks, is programmed under C/C++ and it is divided by domains for managing the functionalities, such as Network, Process, and Node structures. This simulator does not allow modification of the protocols already implemented. NS simulators are a series of different tools proposed by the community (open-source) for network control (NS-2 and NS-3). They are event-based discrete simulators, written mainly in the C++ language [20], and NS has multiple network protocols implemented in different layers (TCP, DSP, FTP, etc.). Due to the open-source philosophy, the NS series of simulators contain multiple configurations and extensions proposed to allow more or better simulations in several specific scenarios [21][22][23].
OMNET++ is an open-source discrete event simulator based on components, written on top of frameworks and C++ libraries [24]. Its modular composition allows the intuitive interaction of its functionalities, from the GUI interface to the delimitation of network protocols [25]. In the same way, this simulator has been extended [26,27]. TOSSIM is defined in [28], a simulator written in NesC (extension of C) and oriented to the functions of IoT and WSN. This tool is used to simulate devices based on the TinyOS system, allowing the simulation by delimiting the actual device drivers themselves. TOSSIM does not capture network parameters such as CPU and power consumption, and some tools or plugins have been proposed to obtain them [29]. The case of mTOSSIM [30], software that extends the TOSSIM simulator, allows the monitoring of a simulation's energy and battery consumption and also offers an external graphical environment that executes TOSSIM simultaneously, displaying the reading of these variables.
On the other hand, the Gbest-WSN simulator is described in [31]. It is a simulation tool oriented towards education since it allows the exploration of the environment, addition of protocols, and comparison of metrics without modifying or learning about the tool's code, unlike others. Gbest-WSN is written in Matlab and allows simulation of static, movable, homogeneous, and heterogeneous WSN protocols. This tool is not available for use. Another tool developed for educational purposes is presented in [32], where the Wireless GINI tool is defined. This tool is an extension of the network emulator GINI toolkit but with the addition of the ability to analyze WSN topologies. The wireless GINI tool allows to setup process-oriented networks and testbed environments with wireless support in an interactive manner, showing examples of multiple topologies and Internet architectures. Another simulator named CloudSim is oriented towards an IoT scope and is presented in [33]. CloudSim simulator is a tool for modeling the cloud computing and infrastructure services that focus on deploying deployment architecture. It offers an option to analyze the management resource usage and their policies and the data center energy consumption. CloudSim also has other extensions allowing the user to execute more specific simulations, such as CloudSimSDN-NFV [34] and iFogSim [35]. CloudSimSDN-NFV is a tool oriented towards Software Defined Networks and their capabilities. The simulator iFogSim allows modeling of the fog computing scenarios in order to analyze and modify the resource management techniques in latency, network congestion, energy consumption, and cost.
Cooja [16] is an emulation/simulation tool for WSN based on the ContikiOS operating system [36]. This tool is a simulator written in Java, which allows the simulation of multiple IoT sensors, communication, and routing protocols. Some research has focused on extending the functionality of the Cooja simulator [37,38]. Taking advantage of the potential of this, they extract information and metadata to achieve other analysis objectives as described in [39], and research which plugins and APIs available to Cooja are used to compile relevant information about weather and surface data. A graphical view is available to show the results of the simulations. In [40], a tool is defined that integrates Cooja with an application based on TinyOS to deploy cyber-physical devices in management and industrial monitoring. Similarly in [37], the implementation of a graphical environment is described, allowing Cooja to run the simulation of a smart house and operate the protocol on closed environments (building, house, etc.).
Additionally, software that model WSN behavior or capabilities are used to extend simulation possibilities. This is the case of [41], where the authors present Viptos, which is a visualization tool for TinyOS nodes related to the TOMSSIM simulator. This tool employs the options presented in VisualSense [42], that at same time is based on the software Ptolemy II [43], where it is offered different kinds of classes and methods for sensor control and communication emulations. Viptos, through the nesC language and PtinyOS [44] framework, integrates VisualSense and TOMSSIM for the running of TinyOS programs (also in hardware devices), allowing the packet-level simulation, the models' additions for building architecture, and so on.
In [45], the NetTopo tool is presented, a Java-based visualization/emulator tool oriented for network algorithm implementations and evaluations. It provides a GUI to show routing algorithms steps, path discovery, and network organization, among other processes. NetTopo is an independent software, meaning that is not based on other simulations' tools, but its implementation contains all the logic for simulating WSN. With the same approach of independency, Netviewer [46] is described. This tool supports the topology and management of communication protocols. Additionally, in different types of environment scenarios this tool presents packets analysis such as volcanic activities and forest analysis, among others. Netviewer is constituted with a replay module for historical review with the visualization of topology and log files of the simulation.
In [47], authors define WiseObserver as WSN visualization tool written in C# and oriented primarily into the results and interpretation of the data generated through a simulation. This tool supports the functionalities of charts by node, interpolation maps, evolution videos, and reports. Among the diversity of state-of-the-art tools and simulators available, ViTool-BC, a Cooja-based tool, is presented to display the information, data, and results of a WSN simulation for the analysis of routing protocols. In addition, this tool allows the extraction and monitoring of Cooja simulations, in terms of the metrics and parameters of interest based on energy estimation models, topology construction visualized step by step, heat maps of energy consumption, and latency calculation, among others. A comparison of different solutions proposed in the literature are described in Table 1. -It is an independent tool that has not specified the real mote controllers that can be executed.
-The energy consumption is not considered.
mTOMSSIM [30] C Tiny OS stack -Considered the Battery level for more real simulations.
-Support indoor and outdoor environments.
-Requires the TOMSSIM simulator execution.
-Interpolation maps of the topology.
-Evolution videos and report from simulation.
-It is an independent tool that has not specified the real mote controllers that can be executed.

ViTool-BC Python
Contiki OS stack -Energy trace and modelling.
-Topology construction -Network parameters management by node.
-Heat map of energy consumption -Required files generated previously on Cooja -Not allow modified topology environment into the GUI.

Energy Estimations and Metrics
For the estimation and monitoring of the network parameters involved in a simulation scenario of a WSN, it is required to have techniques that allow these values to be captured. One of these techniques is constituted by energy consumption considerations, typical of the simulated physical devices to estimate the specific consumption per node. In this paper, the energy model described in Equation (1) is considered as follows: The model described in (1) and based on [48] describes an individual node's consumption after a certain period. The time elapses between the turning on of the mote and the report of its actual state. Each variable in the model has the following purpose: (1) Transmit, which describes the consumption by the transmission action of the node, (2) Listen, which refers to the consumption in the reception state, (3) CPU, which represents the processing cost of logical actions, (4) LPM, that describes the state transition from hibernation to powering on by the nodes, and (5) Voltage, which is the required current for the trigger of a mote These metrics are defined by the time per unit cost of the task and are described in the corresponding datasheet of the selected mode for the simulations. It is expected that by evaluating the network parameters of the simulation, it is possible to obtain or qualify the staging of network topologies and their delimited characteristics, such as the protocol routing, the design, or node locations (random or in uniform formation), and the number of required nodes.

Discussion
In this section, design and the implementation of ViTool-BC over the Cooja simulator is presented. In Section 4.1, the ViToolBC architecture is described, including its main components. Section 4.2 defines the implementation and main characteristics of the tool.

Architecture
The development of a multi-platform desktop application written in the programming language Python and supported by the QT graphical user interface library [49] is defined. This tool is mainly focused on the Linux operating system, due to the direct capability of Contiki OS in one of these distributions (Instant Contiki). Likewise, the results extracted from Cooja from either the Cooja compiled files or from a virtual machine can be interpreted by the tool in any OS.
It is based on the design pattern MVC, which consists of three types of objects in which the Model is the schema of the application, the View is the screen of presentation, and the Controller defines the way the user input is processed. As it can be seen, it is a highly modular and decoupled [50], and could also be described as a design pattern, such as is presented in [51,52]. For management and control of the simulation scenarios, components that describe the core of the system are presented in Figure 1. The system architecture is divided into the modular components and classes that define the system's functionalities.

Simulation Component
This represents the main component for the control of a simulation instance, and is the connection between the final user and the logic process of the executed tool. Among the options available, this component includes: the definition of new simulation scenarios, reproduction of log files, and nodes displayed graphically on the screen canvas. The three main subcomponents are explained as follows: • Mote: It defines the class in which the methods and variables related to a node or device are available within Cooja simulation. This component includes functions and methods such as obtaining the IP address or Rime address, ID of the node, listing and filter of Parent set, energy trace in real time, and remaining battery, among others. These types of procedures allow the tool to show the detailed trace of the current state of each node. • Topology control: The focus of this subcomponent is the generation of random topologies. The resulting random topologies are downloaded into an XML file with a csc extension, which permits to be evaluated in the Cooja tool. Some of the simulation's parameters included in the XML file are the values of node position, TX, and RX. The functionality of this component is restricted to the window commands. • Timer: Subcomponent in which the logic and handling of the simulation time is defined, allowing control actions (play, pause, and reset) of the simulation/replay time value of the scenario. The threads and signals were used to manage and interact with the main window or GUI Thread, due to these types of complements which let the parallel executions of both tasks.
• Timer: Subcomponent in which the logic and handling of the simulation time is defined, allowing control actions (play, pause, and reset) of the simulation/replay time value of the scenario. The threads and signals were used to manage and interact with the main window or GUI Thread, due to these types of complements which let the parallel executions of both tasks.

Graphical Options
For the interactions of the user with ViTool-BC, the platform offers different actions that interact with the simulation and its parameters and metrics. This component describes the views and their options for simulation control and user interactions. The subcomponents that define its functionalities are:

Graphical Options
For the interactions of the user with ViTool-BC, the platform offers different actions that interact with the simulation and its parameters and metrics. This component describes the views and their options for simulation control and user interactions. The subcomponents that define its functionalities are: • QT framework: It is defined as library-oriented towards the software development that will use graphic interfaces (GUI). This library was initially written in C++, but it is available in other programming languages. The library offers routines and methods to facilitate the access and management of the user inputs and visual aspects of the developed applications.
• Parameters controls: There are different options to interact with ViTool-BC, and its parameters are able to manage the visual parameters defined for the simulations. This interaction delimits options such as to modify the topology scale in the canvas, to expand the size of the nodes presented in the simulation, to focus the visualization of the energy consumption in a specific mote, and to activate or deactivate visualization functionalities in the simulation process. • Simulation Control: In the simulation control, components are defined functions to obtain results coming from the simulation to be reproduced. Some of these functions are: the process of managing of the Cooja files (log and csc files), options that will be applied in the simulation, a log in real time related with the executed actions in the reproduction of the simulation, and a graphical display of network topology changing in real time.

Cooja Stack
In the Cooja Stack, there are defined characteristics, options, outputs, and different possibilities offered by the Cooja simulator framework, including the support of different kind of motes and protocols implemented into the ContikiOS. The direct dependency of ViTool-BC with the Cooja simulator comes from data generated in the log and CSC files

Features and Main Components
ViTool-BC is defined as a visualization tool for the data generated by the Cooja simulator, in which multiple network parameters and other monitoring options are included because they are not so evident within the Cooja environment. The main view of the proposed tool is presented in Figure 2.

•
QT framework: It is defined as library-oriented towards the software development that will use graphic interfaces (GUI). This library was initially written in C++, but it is available in other programming languages. The library offers routines and methods to facilitate the access and management of the user inputs and visual aspects of the developed applications. • Parameters controls: There are different options to interact with ViTool-BC, and its parameters are able to manage the visual parameters defined for the simulations. This interaction delimits options such as to modify the topology scale in the canvas, to expand the size of the nodes presented in the simulation, to focus the visualization of the energy consumption in a specific mote, and to activate or deactivate visualization functionalities in the simulation process.

•
Simulation Control: In the simulation control, components are defined functions to obtain results coming from the simulation to be reproduced. Some of these functions are: the process of managing of the Cooja files (log and csc files), options that will be applied in the simulation, a log in real time related with the executed actions in the reproduction of the simulation, and a graphical display of network topology changing in real time.

Cooja Stack
In the Cooja Stack, there are defined characteristics, options, outputs, and different possibilities offered by the Cooja simulator framework, including the support of different kind of motes and protocols implemented into the ContikiOS. The direct dependency of ViTool-BC with the Cooja simulator comes from data generated in the log and CSC files

Features and Main Components
ViTool-BC is defined as a visualization tool for the data generated by the Cooja simulator, in which multiple network parameters and other monitoring options are included because they are not so evident within the Cooja environment. The main view of the proposed tool is presented in Figure 2.  This tool is described by modular features and functionalities, which allows access and management of the simulations generated by Cooja. From the tool, it is possible to reproduce or re-explore these simulations step-by-step in any moment, using the log files generated by Cooja and the base .csc file, in which the arrangement of the nodes on screens and the values associated with the network, such as TX and RX, are delimited. The sequence of the reproduction of a simulation into ViTool-BC is described in Figure 3, including its main functionalities. This tool is described by modular features and functionalities, which allows access and management of the simulations generated by Cooja. From the tool, it is possible to reproduce or re-explore these simulations step-by-step in any moment, using the log files generated by Cooja and the base .csc file, in which the arrangement of the nodes on screens and the values associated with the network, such as TX and RX, are delimited. The sequence of the reproduction of a simulation into ViTool-BC is described in Figure 3, including its main functionalities.

Project Manager
In this option, the handling of simulations is defined through projects and XML files in a chosen format (.vtbc), in which the environment variables are reflected. This vtbc file allows to reproduce the simulation (URLs in the system of the files of interest such as log and .csc) and image control parameters such as battery charge, size of the nodes on the screen, and scale in which they will be displayed into the XML file, as shown in Figure 4.

Timer Control
The tool allows the reproduction of the Cooja simulation; for this reason it is necessary to manage the simulation time. The buttons for time control are "Play", which is defined as to start a simulation, "Pause", to stop the log reading time, and "Reset", to restart the exploration environment. It is pertinent to clarify that the timer runs and compares the actual time in action with the indicated time into the log file generated previously on Cooja. This is in order to consider the next action that the screen should display.

Project Manager
In this option, the handling of simulations is defined through projects and XML files in a chosen format (.vtbc), in which the environment variables are reflected. This vtbc file allows to reproduce the simulation (URLs in the system of the files of interest such as log and .csc) and image control parameters such as battery charge, size of the nodes on the screen, and scale in which they will be displayed into the XML file, as shown in Figure 4.

Project Manager
One of the main objectives of ViTool-BC is to offer easy access and control of the network parameters that are not evident in a Cooja simulation, such as energy trace. A

Timer Control
The tool allows the reproduction of the Cooja simulation; for this reason it is necessary to manage the simulation time. The buttons for time control are "Play", which is defined as to start a simulation, "Pause", to stop the log reading time, and "Reset", to restart the exploration environment. It is pertinent to clarify that the timer runs and compares the actual time in action with the indicated time into the log file generated previously on Cooja. This is in order to consider the next action that the screen should display.

Project Manager
One of the main objectives of ViTool-BC is to offer easy access and control of the network parameters that are not evident in a Cooja simulation, such as energy trace. A color scale shows this tracking, and the color change criterion is delimited (battery green means energy stored over 70%, yellow color represents energy between 70% and 0%, and red node means without energy). In real time, the nodes change their state based on the remaining battery indicated through the tool into a simulation reproduction. These visualizations throw color possibilities into the creation of the heat map of energy of the current topology (as shown in Figure 5). This analysis illustrates the behavior of the distribution and use of the energy in each node that is directed related with the operations or tasks that a node should be doing, such as sensing, sending, forwarding, reception of packets, and messages for maintaining the network connections.

Project Manager
One of the main objectives of ViTool-BC is to offer easy access and control of the network parameters that are not evident in a Cooja simulation, such as energy trace. A color scale shows this tracking, and the color change criterion is delimited (battery green means energy stored over 70%, yellow color represents energy between 70% and 0%, and red node means without energy). In real time, the nodes change their state based on the remaining battery indicated through the tool into a simulation reproduction. These visualizations throw color possibilities into the creation of the heat map of energy of the current topology (as shown in Figure 5). This analysis illustrates the behavior of the distribution and use of the energy in each node that is directed related with the operations or tasks that a node should be doing, such as sensing, sending, forwarding, reception of packets, and messages for maintaining the network connections.

Tree View
This view displays the node connections or tree on the screen during the simulation time (delimitated by minutes), allowing researchers to identify how the nodes are connected and to estimate the network stability. One of the main challenges is to reconstruct the tree of connections into a graphical form. Some approaches were considered for drawing a graph properly, such as the BFS trip and level of each of the connected nodes.

Tree View
This view displays the node connections or tree on the screen during the simulation time (delimitated by minutes), allowing researchers to identify how the nodes are connected and to estimate the network stability. One of the main challenges is to reconstruct the tree of connections into a graphical form. Some approaches were considered for drawing a graph properly, such as the BFS trip and level of each of the connected nodes.

Case of Use: Experiment over RPL Protocol
For interaction with the tool, the initial graphical interface is explored. Some options are disabled, such as the time control and simulation management, because a project on the canvas is not yet displayed. Before the ViTool-BC tool can be used, it is necessary to generate simulation files. This is the reason there is an option named "Cooja" in the menu of ViTool-BC with the choice "Open tool" to open the Cooja simulator. Then, from ViTool-BC, one can proceed to open the Cooja environment to perform the simulation, if Cooja is installed. On the other hand, an error will appear, mentioning that Cooja should be installed.
In Cooja, it is required to configure the process of simulation, including the parameters to be analyzed. For this process, libraries that describe the Cooja platform and its mote are used [53]. Additionally, network protocols are considered for the simulation execution and configuration files offered by ContikiOS. Similarly, for the later reproduction of the simulation in ViTool-BC, it is necessary to consider some modifications in the source code to add in the log parameters that will be visualized in the GUI of the application. Some of them are to authorize the execution of the Powertrace program to print the energy consumption state of each node/mote and to locate code lines in the existing procedure of sending and receiving data packets. One of the examples provided in Cooja, including the collect-tree-sparse-lossy.csc, the test scenario, and its configuration, was executed. The configuration of its simulation is presented in Table 2, including information about the initial state of the execution. These considerations allow defining the test scenario in which the routing protocol is validated. Then, Cooja will execute the simulation with its existing options (as seen in Figure 6); the objective is validated and tests the RPL [54,55] routing protocol into a WSN topology simulation. The execution generates a follow-up in the "Mote output" window, in which a report is displayed in real time of the network actions. A large part of them must be edited and arranged by the researcher/developer. After executing the simulation in the required time, one must proceed in the same window of the "Mote output" to export the simulation log file in a text file. Once the simulation is finished, one must continue to return to the ViTool-BC interface in order to create a new project (Figure 7). After executing the simulation in the required time, one must proceed in the same window of the "Mote output" to export the simulation log file in a text file. Once the simulation is finished, one must continue to return to the ViTool-BC interface in order to create a new project (Figure 7). After executing the simulation in the required time, one must proceed in the same window of the "Mote output" to export the simulation log file in a text file. Once the simulation is finished, one must continue to return to the ViTool-BC interface in order to create a new project (Figure 7). In this window, URL values of the log and .csc files (generated in Cooja), energy of the nodes (this can depend on the energy disposed of Cooja), a width of the nodes, scale of the topology, and expected delay for the time the simulation are entered. After creating a project, the simulation network design is displayed on the selected ViTool-BC environment. From the different components of the tool, the simulation can be followed-up. Then, the simulation results can be reproduced using the time control buttons, and it will start the representation of the topology actions in the graphic canvas. To conduct this process, it is necessary to add the log file with the exported data generated from the Cooja simulation, as seen in Figure 8. In this window, URL values of the log and .csc files (generated in Cooja), energy of the nodes (this can depend on the energy disposed of Cooja), a width of the nodes, scale of the topology, and expected delay for the time the simulation are entered. After creating a project, the simulation network design is displayed on the selected ViTool-BC environment. From the different components of the tool, the simulation can be followed-up. Then, the simulation results can be reproduced using the time control buttons, and it will start the representation of the topology actions in the graphic canvas. To conduct this process, it is necessary to add the log file with the exported data generated from the Cooja simulation, as seen in Figure 8. The actions developed in ViTool-BC are: energy monitoring through color ranges, a direct connection between devices indicated with red lines, sensing information shown in colored lines (no red color used), dynamic displays of the topology construction. All of these are located in the graphic options, as shown in Figure 8a. It is important to take into account that an energy consumption model was built in ViTool-BC to detect the energy of each node, due to this fundamental action not being implemented in Cooja. Another benefit of having this implementation is that researchers can modify or introduce other energy models. The log describes the remaining percentage of each node's battery and latency calculation when sending it to the sink. Thus, each of the nodes presents its infor- The actions developed in ViTool-BC are: energy monitoring through color ranges, a direct connection between devices indicated with red lines, sensing information shown in colored lines (no red color used), dynamic displays of the topology construction. All of these are located in the graphic options, as shown in Figure 8a. It is important to take into account that an energy consumption model was built in ViTool-BC to detect the energy of each node, due to this fundamental action not being implemented in Cooja. Another benefit of having this implementation is that researchers can modify or introduce other energy models. The log describes the remaining percentage of each node's battery and latency calculation when sending it to the sink. Thus, each of the nodes presents its information, as displayed in Figure 9. The actions developed in ViTool-BC are: energy monitoring through color ranges, a direct connection between devices indicated with red lines, sensing information shown in colored lines (no red color used), dynamic displays of the topology construction. All of these are located in the graphic options, as shown in Figure 8a. It is important to take into account that an energy consumption model was built in ViTool-BC to detect the energy of each node, due to this fundamental action not being implemented in Cooja. Another benefit of having this implementation is that researchers can modify or introduce other energy models. The log describes the remaining percentage of each node's battery and latency calculation when sending it to the sink. Thus, each of the nodes presents its information, as displayed in Figure 9. In the created simulator, nodes that lose their energy are eliminated from the graphical view (Figure 8b). Another tool's functionality is the delimitation of the topologies formed through the simulation execution that shows nodes connected in a specific time. It is described as "Tree View" (Figure 10), and the nodes are displayed on screens in a tree topology depending on their link communications. In the created simulator, nodes that lose their energy are eliminated from the graphical view (Figure 8b). Another tool's functionality is the delimitation of the topologies formed through the simulation execution that shows nodes connected in a specific time. It is described as "Tree View" (Figure 10), and the nodes are displayed on screens in a tree topology depending on their link communications. Finally, after the reproduction of the simulation with ViTool-BC, the parameters and metrics analysis allow to conclude that:

•
The considered energy was not enough. More than 50% of the nodes are in the yellow state (less than 70% of battery remaining) after the half of the simulation time.

•
The network stability is maintained; the parent change and communication path changes of all nodes in the network are less than three, on average. These parameters are directly influenced by the disposition of the nodes in the analyzed area.

•
The latency between the nodes is, on average, less than 2 s. The node in the down level takes more time to successfully communicate with the root because multiple hops are implied.

•
At the time 19:01.252, node 3 lost all of its energy and was eliminated for the topology. This information allows the estimation of the network lifetime and could be analyzed and compared between protocols and variations of them. Finally, after the reproduction of the simulation with ViTool-BC, the parameters and metrics analysis allow to conclude that:

•
The considered energy was not enough. More than 50% of the nodes are in the yellow state (less than 70% of battery remaining) after the half of the simulation time.

•
The network stability is maintained; the parent change and communication path changes of all nodes in the network are less than three, on average. These parameters are directly influenced by the disposition of the nodes in the analyzed area.

•
The latency between the nodes is, on average, less than 2 s. The node in the down level takes more time to successfully communicate with the root because multiple hops are implied. • At the time 19:01.252, node 3 lost all of its energy and was eliminated for the topology. This information allows the estimation of the network lifetime and could be analyzed and compared between protocols and variations of them.

Conclusions
In this paper, the design and implementation of the ViTool-BC tool are presented as an alternative to visualizing and configuring aspects on top of the Cooja simulator, aspects which are not implemented in the Cooja tool. ViTool-BC is a graphical desktop application aimed at researchers and developers to enable them to create and implement energy estimation models, visualize WSN topology construction in real time, and create and implement heat maps of energy traces, battery level consideration, and node loss. All these options are oriented to cover the scope of the different possible analyses over a WSN device arrangement. Using ViTool-BC, it is possible to perform a more effective network analysis than is allowed from Cooja. In addition, ViTool-BC includes network parameters and metric evidence into the same GUI of the tool, information that is not found in the Cooja GUI. The authors are currently working on the inclusion of other associated network parameters such as the bandwidth, traffic management, and control of security vulnerabilities. In the same way, in the future, work is intended to detach direct dependence using the Cooja tool.
Author Contributions: P.A.: Conceptualization, software, validation, formal analysis; investigation, writing-original draft preparation; D.J.: methodology, resources, writing-review and editing, visualization, supervision, project administration. Both authors have read and agreed to the published version of the manuscript.