## 4 Main Tools of the WSN-DPCM Platform
### Overview of the Network Simulation Tool
#### 4.2.2 Hardware-in-the-Loop Simulation  
One approach to hardware-in-the-loop simulation is to use input signals coming from the simulation to drive the embedded system under test, thus extracting the output signals from the real setting. Through HiL developed extensions, the simulation environment (_i.e._, OMNeT++/ Castalia) interacts with the real WSN environment (hardware as well as communication channel) to accurately incorporate in the simulation process some aspects of the wireless communication that are difficult (or even impossible) to model mathematically.  
In the context of the project, we focused on two notoriously challenging to simulate aspects of WSN, namely the wireless transmission medium quality and the processing delay introduced by the hardware. HiL testing tools for WSN are anticipated to consist of dozens of physical sensor nodes.  
For this purpose, we extended the OMNeT++/Castalia framework to support the interaction with real WSN nodes and support HiL components by issuing adequate commands towards the hardware as well as receiving respective feedback regarding the performance/behavior of the hardware, which is then integrated into the simulation process. Using the WSN-DPCM network simulation GUI, the user is able to select whether the plugged-in real sensors are to be considered (effectively activating the HiL features) or not. In this context, the developed HiL Simulation Component is able to connect with the hardware nodes running a modified version of the application firmware that includes the interface for data and command exchange with the simulator at simulation run-time. More specifically, the HiL component issues commands and data which are to be conveyed to the actual mode through DT-MW functions. These commands will effectively instruct the hardware to perform well defined and beforehand known operations and collect the respective measurements. The information on operation execution and on respective measurements are then conveyed back to the HiL component, which incorporates them in the simulation process. An abstract view of the interaction flow of the HiL component with the real hardware is shown in Figure 14.  
We use of the \"system()\" function to implement the forward channel, which can execute a command with optional command-line arguments in a shell on a UNIX-like operating system. We executed the Java program responsible for the communication with the motes, along with the required arguments. The reverse channel is implemented using a named pipe.  
Figure 14: Interaction flow between the HiL Component and the hardware node.  
As a proof of concept, we have considered two HiL Simulation Components which tackle aspects notoriously challenging to model in a WSN simulation. The first aspect concerns the hardware processing delay, which in most simulation environments is omitted in the overall delay evaluation. In that respect, for each WSN node the user is able to define which parts of the software stack will be simulated and which will be executed by the available hardware. Therefore, based on specific codes issued to the hardware, the user effectively selects one or more modules of the software stack of a node, to be simulated or executed on the real hardware. In Figure 15, a possible configuration is presented.  
Figure 16: Wireless Medium HiL Scenario.  
Figure 15: Processing Delay HiL Scenario.  
In this case, the user has chosen the routing and the MAC layer of a virtual node to be executed by a physical node, instead of being simulated, while for the second node, the user has chosen only the routing layer. The second approach aims to accurately capture and integrate in the simulation environment the dynamics and unpredictable characteristics of the wireless channel. The above scenario is schematically shown in Figure 16, which allows one to accurately measure the real RSSI and BER, and thus to take into consideration an objective notion of communication link quality.