2. User Manual

2.1. Scenarios

The AML-IP framework is divided in different scenarios or use cases that allow it to exploit all the capabilities AML has to offer. These scenarios work independently of each other and make sense separately, but can be seamlessly combined to create a more complex network. Each of the scenarios rely on a different set of Nodes that perform the different actions required.

For more infromation, check the AML-IP Scenarios sections:

  • Monitor Network State Scenario: performs monitoring, analysis and debugging of the network. The main node in this scenario is the Status Node.

  • Workload Distribution Scenario: distributes high-computation tasks, specifically training data-sets for an AML model, across remote nodes using MultiService over DDS communication. Tasks are divided into Jobs, which are processed by Computing Nodes to parallelize the workload, freeing the Main Node to perform other tasks.

  • Collaborative Learning Scenario: involves Model Manager Receiver and Sender nodes sharing locally obtained models without exchanging private datasets. Using RPC over DDS communication, Receiver Nodes request models based on published statistics from Sender Nodes, aiming to develop more complex and accurate models.

  • Distributed Inference Scenario: distributes large datasets to remote Inference Nodes for parallel processing, ensuring other critical tasks on the main device are not blocked. Using MultiService over DDS, data is efficiently published and distributed, optimizing system performance. Inferences are performed on Inference Nodes and results are sent back to Edge Nodes.

2.2. Nodes

An AML-IP network is divided in independent stand-alone individuals named Nodes. A Node, understood as a software piece that performs one or multiple Actions in a auto-managing way, does not require external orchestration neither a central point of computation. These actions can be local actions such as calculations, data process, algorithm executions, etc., or communication actions as send messages, receive data, wait for data or specific status, etc. Each Node belongs to one and only one Scenario.

There are different ways to run or to work with a Node. Some of them are applications that can be executed and perform a fixed action. Others, however, require a user interaction as specifying the action such Node must perform depending on its status and the data received. In this last case, the Nodes are programming Objects that can be instantiated and customized regarding the action that must be performed.

For more information, check the AML-IP Nodes sections:

  • Agent Node: uses the eProsima DDS Router to connect distributed DDS networks, enabling communication between DDS entities across different geographic locations as if on the same network. It bridges local AML-IP clusters with the broader network over WANs, centralizing WAN discovery and communication. The node supports three types: Client Node (connects to a server), Server Node (waits for client connections), and Repeater Node (forwards messages across LANs).

  • Status Node: subscribes to the Status Topic, receiving status data from all other nodes in the network, and executing a user-defined callback function for each message. It is the main component of the Monitor Network State Scenario. Users can start and stop this node using process_status_async and stop_processing methods, respectively.

  • Main Node: participates in the Workload Distribution Scenario by sending serialized Job Data Types to remote Computing Nodes and receiving solutions as Job Solution Data Types. It operates synchronously or asynchronously: in synchronous mode, it waits for each job to complete before sending the next, using request_job_solution to handle each task sequentially. In asynchronous mode, it employs a callback or listener to process solutions as they arrive, enabling parallel task execution without blocking.

  • Computing Node: acts as a server in the Workload Distribution Scenario, receiving serialized Job Data Types from Main Nodes and processing them to produce Job Solution Data Types. It operates synchronously or asynchronously: in synchronous mode, it waits for each job to arrive and completes processing before handling the next task, using request_job_solution to initiate and manage tasks sequentially. In asynchronous mode, it employs a callback or listener to handle tasks concurrently, allowing for parallel processing and efficient resource utilization.

  • Edge Node: facilitates the sending of data, serialized as Inference Data Type, to remote Inference Nodes for processing. It receives results as Inference Solution Data Types. Operating synchronously or asynchronously, in synchronous mode it waits for each inference to complete before sending the next data batch, using request_inference to manage tasks sequentially. Asynchronous operation employs callbacks or listeners to handle multiple inferences concurrently, optimizing throughput and responsiveness in distributed inference scenarios.

  • Inference Node: functions as a server in the distributed inference process, awaiting serialized data in the form of Inference Data Types from Edge Nodes. It calculates the inference based on the received data and returns the result as Inference Solution Data Types. In synchronous mode, it handles tasks sequentially using process_inference to wait for and process each inference request. Asynchronous operation utilizes callbacks or listeners to process multiple requests concurrently, optimizing performance in distributed computing environments.

  • Model Manager Receiver Node: acts as an active client that interacts with Model Manager Sender Nodes. It receives statistics about available models via statistics_received, then sends requests for specific models using request_model. Once a requested model, serialized as Model Reply Data Type, arrives, it is processed by model_received. This node facilitates collaborative learning by enabling efficient model sharing across distributed networks, enhancing model accuracy and complexity without sharing private training datasets.

  • Model Manager Sender Node: acting as a passive server that manages and distributes models. It sends out statistics about the models it manages using publish_statistics, then waits for incoming requests for specific models serialized as Model Request Data Type. Upon receiving a request, it executes a user-defined callback function fetch_model to generate and return the requested model as Model Reply Data Type. This node facilitates collaborative model sharing across distributed systems, enabling efficient and secure model exchange without sharing underlying training data.

  • Fiware Node: integrates with a FIWARE context broker to handle inference data, bridging data retrieval, inference requests, and posting results back to the broker. It reads data from a context broker entity, requests inference from an Inference Node, and posts the inference result back to the context broker. It includes an Edge Node to facilitate inference requests.

2.3. Tools

2.3.1. Agent Tool

This tool launches an Agent Node, which is the node in charge of communicating a local node or AML-IP cluster with the rest of the network in WANs. It centralizes the WAN discovery and communication, i.e. it is the bridge for all the nodes in their LANs with the rest of the AML-IP components.

For more information, check the AML-IP Agent tool section.