arch
The EviNS framework running on the Erlang virtual machine comprises a set of independently running agents (see the figure below). Each agent is explicitly defined in the form of a finite state machine or a pushdown automata and is driven by events generated externally by interface processors or internally by event handles or timers. Each agent is fault-isolated. Incorrect agent implementation should not affect the behavior of an agent which doesn't have any errors.
The agent is a self-contained software component that provides a well-defined functionality, and has well-defined interface specifications for message exchange. Agents can play a role of a network stack protocols, or solve some particular computational task or play a role of an inter-agent between external sensors and acoustic modem in order to optimise data exchange through the acoustic channel.
Agents are connected to each other and to external processes via interface processors, converting raw data coming from external interfaces to well-defined messages and messages received from the corresponding agents back to raw data. Each agent specify particular interface processors required to be connected to it. Agents are agnostic to the source of messages. It is a configuration task to wire all the agents together and to external interfaces via interface processors compatible with corresponding agents. Agent configuration can be either predefined in a configuration file or generated on the fly via interaction with a watcher, the framework configuration agent.
An agent together with interface processors can be treated as a virual device wired through configurable physical or virtual interfaces to other components.
The EviNS framework implementation follows Erlang/OTP design principles for how to structure Erlang code in terms of processes, modules and directories. The Open Telecom Platform (OTP) is a large collection of libraries for Erlang.
A basic concept in Erlang/OTP is the supervision tree, a process structuring model based on the idea of workers and supervisors. Workers are processes which perform computations, that is, they do the actual work. In our case these are agents, interface processors and the watcher. Supervisors are processes which monitor the behavior of workers. The supervisor can restart a worker if something goes wrong. Figure below shows the general supervision tree of the EviNS framework.
The fsm_supervisor monitors fsm_watch, the framework configuration agent, and agent supervisors fsm_mod_supervisor. If either the framework configuration agent or one of the agent supervisors crashes, it will be restarted by the fsm_supervisor not affecting the other running modules. Each fsm_mod_supervisor is configured and run by fsm_watch. According to its configuration, each fsm_mod_supervisor runs and monitors modules, implementing behaviors of fsm_worker, role_worker and fsm, where behaviors are formalizations of common patterns and are part of Erlang/OPT. The idea is to divide the code for a process into a generic part (a behavior module) and a specific part (a callback module).
The role_worker behavior takes care of communication via interfaces supported in the framework. Earlier referred interface processors are implementations of the role_worker behavior. For a new behaviour implementation it is required to define callbacks, responsible for parsing the raw data into user defined data structures (to_term) and for generation of raw data from user defined data structure (from_term), initialisation callback start, configuration callback ctrl and stop called when the process is terminated. The fsm_mod_supervisor can supervise several interface processors according to the agent configuration. Useful examples of the interfaces processors are role_at (EvoLogics S2CR modem interface parser) and role_nmea (NMEA interface parser).
The fsm_worker behavior maintains the agent initialisation, interconnection of the agent with the interface processors. The behavior implementation should define only two callbacks, a start callback and a register_fsms, responsible for the initialisation of the agent based on configuration data.
The fsm behavior runs a finite state machine or a pushdown automata, defined in the behavior implementation, referred above as the agent. In order to define the agent, a finite state machine must be declared in an explicit form as a structure, defining the states and transition to other states and must be returned by the trans callback. Additionally callbacks init_event and final must return initial and final events of the finite state machine respectively. The central callback for event processing is a handle_event that preprocesses the incoming messages. Here these messages received from the interface processors or from timers are transformed into events of the particular state machine. For each state a corresponding handler must be created, called on each event occurrence. The start_link, init and stop are called on process creation, its initialisation and termination. As a simple example of the agent implementation can be taken fsm_triv_alh implementing Aloha MAC protocol.
Agents can interact with other agents and with external applications using interface processors of different types (see figure above). Four types of interface processors are supported:
- TCP socket: tcp. This is the most common interface type, used by the interface processors, that can be used both for agent-to-agent and agent-to-external application interaction
- Erlang port: port. Ports provide the basic mechanism for communication with the external world, providing a byte-oriented interface to an external program. This interface type can be used for the interaction of the agents with external applications only
- Erlang message queues: erlang. These interfaces can be used for direct message exchange between agents without data parsing by interface processors
- Cowboy HTTP server: cowboy. Cowboy is a small, fast and modular HTTP server written in Erlang. This interface type converts user actions in a web browser to messages delivered via interface processors to agents and generates necessary responses to the user requests.