Edge Services Architecture

The following topics describe the key components and services that enable Octave to capture, manage, and communicate data.

Data Hub

Octave's Data Hub is the hub of control system data flow on an edge device:

Sensor data samples flow into it, while actuator control setpoints flow out of it, and processing apps such as the Action Runner, receive data samples from the Data Hub and push results back into the Data Hub.

More generally it is designed to enumerate available data sources (inputs/sensors) and sinks (actuators/outputs), provide filtering and buffering of input data, direct the flow of data between apps connected into the Hub, and provide administrative interfaces for dynamic discovery of I/O points, setting and clearing overrides, and configuration of the Hub itself.

High-Level Goals

The high-level goals of the Data Hub are:

Take input of time-stamped data (pulled or pushed) from producer/source apps (such as sensor drivers and data processing apps like the Action Runner.
Filter input data to optimize the data traffic.
Push output of data to consumer/sink apps (such as actuator drivers and data processing apps like the Action Runner).
Push configuration settings to producer/source and consumer/sink apps.
Buffer time-stamped data and provide access to those buffers to data consumer/sink apps (such as the Cloud Interface and data processing apps like the Action Runner).
Enumerate I/O resources and allow administrative apps (such as the Cloud Interface) to walk the list to discover I/O points.
Allow administrative apps (like the Cloud Interface) to configure the buffering, filtering, and routing of data between inputs and outputs within the Data Hub.
Allow consumers to perform queries on input data buffers and iterate over those buffers.
Allow administrative apps to set overrides on I/O points, clear overrides, and discover what overrides exist.

Access and Usage

The Data Hub is involved any time you use the Cloud Interface or Octave API to interact with an Edge device.

The Octave API provides the Datahub.read() and Datahub.query() functions for programmatically interacting with the Data Hub in Acton Runner. For more information see: Action Runner Octave Functions.

Data Hub Implementation

The Data Hub is implemented as a Legato application, meaning it is an open-source application, contributed to the Legato project itself, and is a core component of Octave's Edge architecture.

Action Runner

The Action Runner provides a JavaScript execution environment for the Actions (which are JavaScript functions) and runs the appropriate Actions when their configured triggers are received from the Data Hub:

The Cloud Interface provides CoAP resources allowing the Cloud to discover and modify Actions. This CoAP interface is intended for use during "Responsive Mode", which is used during development or in-the-field debugging, but it doesn't scale to fleet-scale deployments. To push out to a fleet, the Actions are built into the Cloud Interface itself as JavaScript files, and the Cloud Interface app is deployed to the fleet.

The Action Runner is implemented as a Legato service / application capable of executing JavaScript functions (ECMAScript 5.1 or above). The Action Runner can perform the following functions:

Load Actions into memory, update Actions already loaded, and delete Actions from memory; and
Execute Actions with a provided payload as the input parameter

The return value of an Action includes both the outbound payload(s) and where the payload(s) must be sent.

Writing Actions

Actions can be written directly in the Octave Dashboard when creating/editing Cloud and Edge Actions, or by using the Cloud and Edge Actions APIs.

Information on how Actions are written and handled by the Action Runner is available in the Action Runner Reference.

Cloud and Edge Action APIs

The Cloud Action object in the Octave API can be used to programmatically create, manage, and simulate cloud actions that are executed by the Action Runner.

The Edge Action object in the Octave API can be used to programmatically create, manage, and simulate edge actions that are executed by the Action Runner.

Cloud Interface

The Cloud Interface service bridges the Data Hub and Octave in the cloud:

The Cloud Interface has two main responsibilities:

receive configuration settings and real-time commands from the Cloud (i.e. the Octave dashboard) and relay them to the Data Hub and the Action Runner. For example, when setting the value of the /lcd/txt1 resource, the change will be propagated to the device over the cellular network. The Cloud Interface then takes this change, sends it to the Data Hub, where the LCD driver will read the update and display the new value on the screen.
receive data samples from the Data Hub and relay them up to the Cloud. As part of this functionality, the Cloud Interface provides a buffer for events to store, and allows you to dynamically configure how often that buffer is sent to the cloud (i.e. Store and Forward). It also allows the Cloud to discover the I/O resources available on an edge device.

Access and Usage

The Data Hub is involved any time you use the Cloud Interface to interact with an Edge device.

Data Hub Implementation

The Cloud Interface is implemented as a Legato application, meaning it is an open-source application, contributed to the Legato project itself, and is a core component of Octave's Edge architecture.

Octave Resource Protocol

The following topics describe the Octave Resource Protocol, which is the protocol that facilitates communications between your assets, Octave-enabled device, and the cloud:

Modbus

Modbus is a reasonably old protocol but is popular for enabling communications between PLCs and other industrial equipment. A Modbus system consists of one master that initiates communication with multiple slaves, each of which are accessed by unique addresses. It uses either a multi-drop serial bus (RTU) over RS485 or RS232, or a socket-based TCP over IP connection. Secondary RTU buses can be connected to TCP servers for extending the bus over IP.

Registers

The Modbus protocol uses a simple a register read/write architecture. A registers can be one of four types:

Coil, Read-write 1 bit
Discrete input, Read-only 1 bit
Input register, Read-only 16 bits
Holding register Read-write 16 bits

Registers are only 16-bits wide and therefore this requires some manipulation when using more complex variables, such as floats and structures. For example, 32-bit floats are typically distributed across two 16-bit registers. Also, data which is smaller than 16-bits is sometimes packed into a single register with other data. For example, a 6-bit sensor value may occupy 6 of the 16 bits in a register and the remaining 10 are used for something else.

Additional Modbus Information

For more information on the Modbus protocol, see:

Octave Modbus Overview

An edge device can interact with Octave by sending and receiving information through an Octave-ready device such as an AirLink FX30S over Modbus to one or more slaves. The Octave-enabled device contains an Octave Datahub which is responsible for communicating with the Octave cloud service.

Functionality and Support

Octave provides the following functionality and support for Modbus:

Communication over an RS485 RTU bus.
Communication over a TCP bus.
Communication with multiple slaves on a bus.
Read and write access to all registers of each slave.
Can create distinct resources in the Data Hub for the movement of data to and from a slave.
Periodic reading (polling) of arbitrary registers of any slave and post the results to the Data Hub.
Multiple simultaneous polling rates for different registers.
Provide an indication in the Data Hub of the status of any read or write operation.
Allow all Modbus-specific parameters, such as bus type, slave addresses, etc. to be changed through the Octave dashboard.
Allow the names of resources created in the Data Hub to be configured through the UI.

Manipulating Register Data

The use and manipulation of register data is specific to the customer equipment and needs. As such, Octave's Modbus feature does not perform any built-in data manipulation. Instead, customers may use actions, either at the edge or in the cloud, to manipulate register values as needed.

Octave Modbus Architecture

The following diagram shows an Octave-enabled IoT edge device (1) and how it supports Modbus:

The device has an RS232 serial port (2), RS485 serial port (3), and Ethernet port (4).

Within the edge device, Octave consists of:

a serial service (5) that defines the serial interface connection settings (e.g. baud rate, parity, etc.) which is configured via Device > Services in Octave;
the Modbus Master driver (6) that handles Modbus protocol communications with an attached slave.
the Data Hub (7) which performs all Octave communications with Octave cloud; and
the mapping configuration (8) which stores information about the Modbus configuration.

In this architecture, the Data Hub communicates with the Modbus master driver, which in turn performs read and write operations that were invoked via Octave (either via the cloud interface or through the Octave REST API).

Octave allows you to organize slaves into one or more groups. A group is used to avoid having to create an individual resource for each register and provides a path as a resource for the registers on the Datahub.

Data Hub Resources

Modbus data is communicated through the Data Hub. Values which are read from Modbus slave registers will appear as an input resource, and values which are written to slave actuators will appear under an output resource. A configuration resource will reside at the top level and will determine the configuration of sub-levels. The top-level, or master, is capable of supporting multiple buses and each bus can support multiple slaves. Slave-specific resource paths will therefore consist of a bus name and slave name.

Additional Information

For additional information see: Modbus Guides