## 3 The Concept of Building the EviNS Software Framework
As for the types of interface handlers, the EviNS framework utilizes four types of interfaces for different types of interactions among agents and external applications (Figure 3) (URL: [[https://github.com/EvoLogics/evins/wiki/arch](https://github.com/EvoLogics/evins/wiki/arch)]([https://github.com/EvoLogics/evins/wiki/arch](https://github.com/EvoLogics/evins/wiki/arch)) (accessed on 5 October 2022)):  
1. TCP Socket: this is the most common type of interface handler used for interaction between agents as well as between agents and external applications. 2. Erlang Port: this type of interface handler serves as the primary mechanism for communication with the external world and is exclusively used for interactions between agents and external applications. 3. Erlang Message Queue: this interface type enables direct message exchange between agents without the need for syntax parsing by interface handlers. 4. Cowboy HTTP Server: Cowboy is a lightweight, fast, and modular HTTP server written in Erlang. This interface type translates user actions in a web browser into messages delivered to agents via interface handlers and generates necessary notifications in response to user requests. It is worth delving into this further. Currently, EviNS includes the AT Commands role, which serves as a syntax parser only for commands specific to Evologics modems. However, there are numerous modem manufacturers who do not have a direct means to utilize EviNS protocols for their own network communication tasks. To address the integration of arbitrary modems with EviNS, two approaches can be taken. The first involves modifying the AT Commands role to enable the protocols of the data link and network layers to work with the commands of the chosen modem. The second approach entails embedding additional roles into EviNS alongside the AT Commands role, providing the ability for the protocols of the data link and network layers to work with commands from third-party modems. This is illustrated in Figure 4.  
To connect any other modem to EviNS, the software framework must include an additional (newly developed) modification of the medium access control protocol, as well as an additional (newly developed) modification of the network protocol. In other words, as many modems need to be connected to EviNS, an equal number of modified or newly developed protocol pairs must be included in the software framework. For each modem, there will also be a need to develop a role responsible for parsing commands specific to that modem. Due to the openness of the EviNS source code, all of this is achievable. However, implementing such changes would require significant modifications to the software framework. In many respects, altering a well-functioning software framework is undesirable. Therefore, another approach could be considered, which involves not modifying the software framework but rather adding applications to it that are inherently capable of  
Figure 4: The structure of the interaction of hydroacoustic modems with the Evans (v2021) software framework in its current version. Figure 3: Types of interfaces used in the EviNS software framework. working with multiple modems (with different roles). This is illustrated in Figure 5--in addition to or instead of the existing protocol, a protocol could be developed that works not only with the AT command role but also with roles of other commands. This approach could significantly reduce the costs associated with expanding the capabilities of the software framework, particularly by enhancing its ability to create hydroacoustic networks based on modems from different manufacturers. In turn, this would contribute to broadening the scope of tasks related to the Internet of Things in the maritime domain. As a part of the current project to expand the capabilities of the software framework, custom protocols for the medium access control and network layers have been developed.