Embedded Edge Agent

The Embedded Edge Agent (EEA) provides a way to embed WEGnology’s Visual Workflow Engine directly into your own edge applications. The EEA extends WEGnology’s workflow functionality to nearly any environment, language, or operating system (OS).

The EEA is designed to be used in resource-constrained environments with a minimum of 2MB of memory. By embedding the EEA into your edge application or firmware, your devices gain the ability to dynamically and remotely change behavior using WEGnology’s low-code workflow editor without requiring over-the-air (OTA) firmware updates.

EEA Use Cases

The EEA’s low resource requirements and flexible deployment options enable a wide variety of use cases for both IoT solution developers and ecosystem vendors.

Embedded IoT Gateways

Not every IoT gateway is capable of running WEGnology’s full Gateway Edge Agent (GEA). Many gateways, even if they run Linux, have constrained resources or a Linux image that is incapable of running all required dependencies of the GEA (e.g. Docker). The EEA greatly expands the number of gateways that are capable of running WEGnology workflows.

Whether you’re a gateway vendor or a gateway user, the EEA delivers unparalleled control and agility over the gateway’s functionality. Gateway vendors can offer an out-of-the-box edge application that greatly improves the gateway’s value by allowing customers to remotely control and orchestrate the gateway’s features using WEGnology’s low-code workflow editor.

Many gateways have what’s known as “application space”. This allows gateway users to deploy custom applications to perform domain-specific tasks on that gateway. Since the EEA is extremely portable, it is likely that you can deploy an application that supports the EEA and Embedded Workflows. This allows your team to dynamically change the behavior of your custom application without changing code.

IoT Devices and Sensors

The EEA does not require an operating system, which makes it a good fit for directly embedding into the firmware of IoT devices and sensors. In most cases, we recommend a minimum of 2MB of memory, but this may be less depending on the number and size of your workflows.

The EEA has built-in functionality for vibration data, including FFT and RMS analysis. This makes it a perfect fit for vibration use cases, such as industrial equipment monitoring or shock and vibration tracking. By embedding the EEA into your firmware, it greatly extends the flexibility of your device by allowing remote updates without requiring code changes or firmware OTA.

Sensor manufacturers can embed the EEA directly into the device’s firmware to provide customers entirely new ways to control and customize their devices.

How the EEA Works

The EEA works by compiling every workflow deployed to a device into a WebAssembly module. The module also contains a WebAssembly Edge Agent that manages workflow execution. Whenever a workflow is deployed, WEGnology compiles the WebAssembly module and publishes it to your device(s) over MQTT.

The WebAssembly module communicates with your native code through an interface defined by the Embedded Edge Agent API. The EEA uses standard WebAssembly with no external dependencies. This means the EEA can be embedded into any language, with or without an OS, as long as the language supports a WebAssembly runtime. The EEA Examples repository contains applications written in Python, JavaScript, and C++ (ESP32).

Since the EEA can be deployed in nearly any environment, with or without an OS, the EEA does not have the knowledge or ability to directly access system resources. Common system resources include, but aren’t limited to:

  • Sockets (MQTT)
  • Peripherals (GPIO, I2C, Serial, etc.)
  • Flash storage and/or the file system

Your edge application’s code, therefore, is responsible for interfacing with all required system resources. The EEA API, and specifically registered functions, eea_send_message, and the Direct Trigger, provide a way for your Embedded Workflows to interface with your application code. For example, your device may have an I2C accelerometer. The EEA cannot directly access I2C devices since I2C works differently on every device and every OS. Therefore, a good use of a Registered Function Node is to invoke a function in your application code that can read the accelerometer data and return it back to the workflow payload.

Differences Between the EEA and GEA

The Embedded Edge Agent (EEA) and Gateway Edge Agent (GEA) work in very different ways and solve very different problems.

  • The EEA is designed to be embedded into another application. It extends that application with the ability to execute Embedded Workflows. The EEA, by itself, has no ability to directly communicate with any system resources. Therefore, the application it is embedded into must provide the code to communicate with system resources like sockets, GPIO, I2C, Serial, or the file system. Your application and the EEA then interface with each other using the EEA API. The EEA is designed to be deployed in resource-constrained environments.
  • The GEA is a standalone service, deployed via Docker, that runs on most Linux gateways. You can think of the GEA as an app that gets installed on your gateway. The GEA is a service that runs Edge Workflows and offers much more capability out of the box when compared to the EEA. The GEA includes its own MQTT client and direct integrations with many existing industrial protocols. Because the GEA comes with a significant amount of capability out of the box, it is designed for Linux gateways with a moderate amount of resources (512MB+ of memory, 8GB+ disk space).

In most cases, if your device or gateway is capable of running the GEA, that’s what we would recommend. The EEA requires custom code. If your organization does not have expertise in one of the languages that supports a WebAssembly runtime, the EEA may not be an appropriate fit.

Getting Started with the EEA

To get started with the EEA, we recommend the following resources:

  • The Embedded Edge Agent Walkthrough: This document provides step-by-step instructions that will first get you familiar with WebAssembly and end with you deploying your first Embedded Workflow to a Python edge application.
  • How to Process Accelerometer Data using the EEA and Raspberry Pi: This guide provides step-by-step instructions using a real-world scenario of an accelerometer attached to a Raspberry Pi. This guide demonstrates how to use a Python edge application to interface with the accelerometer and pass that data to the EEA for FFT and RMS analysis.

Was this page helpful?

Still looking for help? You can also search the WEGnology Forums or submit your question there.