## 5 Proposed Software-in-Loop System
### Software-in-Loop Scheme  
The original (not _software-in-loop_) software architecture of the underwater node, shown in Figure 3(a), comprises three main executable software programs: client, server, and STNAAG 5066 stack. These processes communicate between them using TCP/IP sockets. Acquirer is a Python script that reads sensor values from a UART, and also uses TCP/IP to send the fetched data to the client. Both client and STNAAG 5066 stack programs need no modification to be integrated under the proposed real-time simulation scheme. Thus, the same version of both programs is used either for deployment and for _software-in-loop_ simulation. Acquirer and interface are the only two software blocks in the server program that have to be adapted. A new server interface was coded in order to handle the incoming and outgoing data of the simulator, instead of handling it on a physical modem. Acquirer was changed by a _fake_ acquirer, because there are no available sensors in the simulated environment Figure 3(b). The characteristics of the fake acquirer are explained in Section 6. In essence, the system's software dependency on a real node platform (software does not need to access a real modem neither real sensors) has been removed, allowing it to run in a common PC, in a hardware-agnostic manner. Furthermore, several nodes can be simulated in a single PC. In order to complete the _software-in-loop_ simulation scheme, it is necessary to define how the simulator communicates with the new server interface. \begin{table}
\begin{tabular}{c c} \hline \hline
**Parameter** & **Value** \\ \hline \(L(d_{0})\) & 63.06 dB \\ \(\eta_{1}\) & 7.25 \\ \(\eta_{2}\) & 3.66 \\ \(\sigma_{X}\) & 0.748 dB \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Channel parameters used in this work. A simulator has been specifically designed as part of the simulation environment developed for this work. This software block is necessary because the software inside the loop is a real-time stack (STANAG 5066), and it was not possible to integrate it with a DES. These simulation environments use _next-event time progression_ techniques for accelerating time between different queued events. Nonetheless, the platform must be omniscient, since all the queued events are internally handled. These simulators require the specific implementation of all the software to be tested using the simulator API, which is time-consuming and does not offer the possibility of evaluating real-time software under controlled environmental conditions. These restrictions are completely incompatible with the use of STANAG 5066 stack, as this software is compiled under GNU/Linux OS, and it uses its own event queue and timing integrated with OS system calls. The simplified simulation algorithm is depicted in Figure 5. This algorithm shows that the simulator can be considered as a DES using fixed-increment time progression (resembling a continuos simulation scheme), but every time slice is incremented in real-time. The size of the time increment is represented by \(\Delta t\). Internal simulator events represent transmissions made by any node. Once the transmitted message (using the server's interface) is received by the simulator, it adds the message to the internal event queue. Then, all the queued messages are consumed in \(\Delta t\) steps. The remaining data is still queued to be consumed in the future. If there is no queued event, a wait cycle is performed. The selection of \(\Delta t\) value is a trade-off between computational efficiency and real-time event handling capacity. Small values (1 to 50 ms) of \(\Delta t\) imply that an event-handling cycle is performed very frequently. Therefore, the simulator program will take a high CPU usage. For higher values of \(\Delta t\), the CPU usage will decrease, but transmissions that were generated within the handling cycle will be time-aligned to the next starting cycle.