Architecture
Base components
| NuvlaEdge Component | Description |
|---|---|
| AGENT | The agent is the beating heart of the NuvlaEdge. It is responsible for the NuvlaEdge activation, commissioning and monitoring procedures. All outgoing communication towards Nuvla pass through the agent, via its internal REST API. |
| SYSTEM MANAGER | The system-manager is the NuvlaEdge’s watchdog. It runs independently of all the other components. During the NuvlaEdge bootstrap, it double checks that the device has the minimum requirements to support a NuvlaEdge, and if so, it starts scanning the whole NuvlaEdge on a periodic basis, searching for faulty NuvlaEdge containers and trying to fix them automatically. It also provides an internal dashboard on the host’s 127.0.0.1:3636 endpoint, with the overall status of the NuvlaEdge. |
| COMPUTE CREDENTIALS MANAGER | Also referred to as the “COMPUTE API”, this component makes sure all synchronous communications between Nuvla and the NuvlaEdge, for application management, are secured. |
| VPN CLIENT | The standalone vpn-client component is solely responsible for picking up an OpenVPN configuration set by the agent and establishing a secure VPN tunnel with SixSq’s VPN server (or any other desired VPN server), ensuring that the NuvlaEdge is always remotely accessible. |
| DATA GATEWAY | The NuvlaEdge data-gateway is an abstraction layer between user applications and IoT sensors/actuators. This component consists of an MQTT Broker (i.e. Mosquitto) which sits behind an internal shared network (the nuvlaedge-shared-network). Depending on whether the NuvlaEdge is operating in cluster mode or not, this component can either take the form of a standalone container behind a bridge network, or a load balanced service behind an overlay network. This configuration switch is handled automatically by the System Manager. Additionaly, and optionally, the NuvlaEdge can also be deployed with the Data Gateway’s FIWARE Processor, which is a sidekick micro-service that validates the schema of MQTT data, against FIWARE’s data models, and upon successful validation, forwards data to a configurable outgoing endpoint. |
| JOB ENGINE LITE | The Job Engine Lite is a lightweight version of the job processing engine behind Nuvla. Its introduction to the NuvlaEdge architecture allows users to remotely schedule operations to be executed inside the NuvlaEdge, even if the edge device happens to be unreachable at the time of the operation was issued. |
Additional components
The NuvlaEdge has the concept of Peripheral Managers. These are optional micro-services which perform automatic detection and categorization of peripherals that are or can be connected to the edge device. Such peripheral information can then be used to activate sensor data acquisition throught the Data Gateway.
| NuvlaEdge Peripheral | Description |
|---|---|
| SECURITY | The security component is an autonomous self-assessment entity which scans the edge device on a configurable periodic basis, looking for vulnerabilities. Each potential vulnerability is compared with public reference databases (like the CVE) for a full categorization of the problem. These databases are also kept up to date via an internal synchronization procedure which is also scheduled with a configurable frequency. The most critical vulnerabilities are sent to Nuvla (via the agent). |
| USB | The peripheral-usb component scans the UBS ports in the device. It allows the deployed apps to quickly find USB devices |
| BLUETOOTH | The peripheral-bluetooth component scans the surrounding for open bluetooth devices and reports them to Nuvla so apps can access which devices are available |
| MODBUS | Serial port discovery tool for PLC modbus connections |
| NETWORK | Scans for devices connected to the same network (In the default gateway) of the device. The network peripheral is responsible for the discovery, categorization and management of all NuvlaEdge network peripherals. |
| GPU | Allows applications to access the GPUs available in the device. |
Peripherals expected output
All different peripherals report a basic set of information allowing Nuvla to identify and categorize them:
- Name: Generic peripheral name
- Description: (Optional) Contains a detailed description of the detected device
- Identifier: (Unique) This unique identifier is provided by the peripheral manager. Besides the UUID that will be generated by Nuvla, this ID is generated in the Edge.
- Classes: Serves as categorization field depending on the type of peripheral
- Interface: The major categorization field. One peripheral can create more than one type of interface. Peripherals tab in the Edge representation in Nuvla will be categorized at first using this field.
- Available: Marks whether the device is online or not
- Vendor: (Optional) If exposed by the device, reports the brand name
Some peripherals report additional data:
USB
- product: Product name or ID depending on the exposed information
- device-path: Host system path there the device is mounted
- serial-number: If exposed, the serial number of the USB device
- video-device: When the USB corresponds to a video device
GPU
- Resources: Total available resources in the detected GPU
- Memory
- CPU Count
- Memory
- System device paths: Paths where the GPU is exposed to the system as a device
- Libraries: Libraries installed in the host system
MODBUS
- Port: Network port where the device is exposed
Network
- device-path: Local IP address of the detected device
- product: Category of network device
- serial-number: Unique identification of the detected device. Usually corresponds with the MAC address
Network Port Binding
| Port | Usage | Protocol | Description |
|---|---|---|---|
| 443 | Outbound | TCP | Used by NuvlaEdge to communicate with Nuvla via HTTPS (https://nuvla.io) |
| 1194 | Outbound | UDP | UDP connection to vpn.nuvlaedge.com in case VPN is decided to be used for communication with the edge device managed by NuvlaEdge. |
| 3636 | Internal | - | This port is used by the system-manager to publish the internal NB dashboard |
| 5000 | VPN/Inbound | - | Used by the compute-api as the relay endpoint for Docker. Ingress must be allowed |
| 5080 | Internal | - | This port is used by the agent to provide the internal REST API for other NB components to speak with, internally |