System Description

Mainflux is used as a middleware, that means as a SW server (set of servers in fact) that provides several functionalities and services that are usually needed in designing IoT applications.

This way IoT product and application designers can use already tested and proven block (Mainflux) and focus only on their devices and end-user application.

In the following picture:

we can see that Mainflux is the middle block that does a lot of the heavy lifting. IoT product designer can re-use this block and focus only on the leftmost part - his device (physical design, firmware, etc) and rightmost part - his end-user application (GUI application that controls the device).

Mainflux will connect device and application and relay messages beween them in highly secure manner, while offering a lot of other services needed for device and application management.

Here is (and incoplete) list of services that are offered by Mainflux, and we will explain each of them in closer details:

• Messaging bridge - relays messages between devices and applications
• Device manager - accepts device connections on southbound interface
• Application manager - accepts application connections on northbound interface
• User manager - provides user management for the applications
• Time-series storage engine - stores and queries measurements datapoints in the time-series format
• CEP machine with rules engine - it does Complex Event Processing of incoming time-series streams and can automatize triggers and actions based on configurable set of rules

Message Relay And Multi-protocol Bridge

Mainflux is thus message bridge to interconnect applications and devices.

Both applications and devices can be context providers and/or context consumers. For example, in one scenario one device can be a temperature sensor (provides temperature measurements) and send it to Mainflux, which relays it to some application which presents this measurement in the GUI (thus it consumes them). In some other scenario device can be an actuator (consumes commands) - for example smart lock with electromotor to lock/unlock the door. An application that commands the lock would be a context provider in that case.

There are of course scenarios in which application can be both context provider and consumer, or scenarios in which two or more
applications (or devices) exchange messages between them (it is not necessarily direct path app-device, it can be Device-to-Device - or as we say M2M (machine-to-machine), App-to-App, and so on).

Mainflux is "multi-protocol" messaging bridge because it supports several networking protocols that proliferate in IoT world:

• HTTP
• WebSocket
• MQTT
• CoAP

Device Manager

Mainflux holds the internal representation (data structure model) of every device provisioned in the system. This model represents the current state of the device.

Each device that connects to Mainflux thus has it's own model (record, structure) in the internal Mainflux database (device registry) which is regularely updated by the device. So, when device changes internal (physical) state it sends UPDATE request to Mainflux, and then Mainflux changes it's model (record, structure) in it's internal database. As a consequence, when the application (or some other device) now queries database, they find new (updated) device model - and this way information (message) is relayed from device to application (and vice versa).

Having in mind that Mainflux has all these internal device models and it keeps devices connected to it, we can use Mainflux to manage devices - i.e. to obtain various type of device management information, like:

• How many devices are connected
• Where are the located
• What is the firmware version
• What is the battery status
• What is the serial number of each device
• And so on

We can also use Mainflux to send various commands to devices as a part of device management process:

• Enable/disable device
• Push firmware updates
• Group devices or change access privileges
• And so on

User and Application Manager

Mainflux is multi-user and multi-tenant application management platform. That means that it enables Mainflux users (of type developer) to create new multi-user applications on the top of Mainflux without the need to handle their end-users themselves - Mainflux solves user management for these applications.

In this sense Mainflux is similar to Twitter or Facebook - creating Mainflux application should be a process similar creating a Twitter application for example:

• User creates developer account on Mainflux
• User creates new application using Mainflux public API
• User develops his application that calls Mainflux public API for user creation, messaging, management, etc...

Main point here is that this "Mainflux application" can itself be multi-user. So, Mainflux is a multi-user platform (it can have many user accounts, some of which are of type developers), but it can host a multi-user applications themselves.

Time-series Storage Engine

Besides keeping a current device state (representation) in the internal MongoDB database, Mainflux allows timestamped data to be kept in a specialized time-series database (InfluxDB) for purpose of keeping the historical information.

That means while MongoDB keeps current state of device, InfluxDB keeps many timestamped data points (most often measurement values) and application can present graphs based on this data points. For example - what was the temperature measured by sensor XY in last 10 days? Or what was the crop field average humidity in August in last 5 years? Or what was the river level in spring in last 3 years. And so on.

Let's say that temperature sensor is sending one temperature measurement every minute - so 60 x 24 = 1440 times per day. There will be 1440 data points written in InfluxDB with adequate timestamp for each measurement (time-series data format is tuple (<timestamp>, <value>)). When application demands temperature history for the last 10 days, Mainflux will query InfluxDB and return to the application 10 x 1440 = 14400 data points read from the database, which application will use to draw a graphical representation (for example function graph) of the temperature.

Most of the industrial IoT use-cases are closely tied to telemetry. Sensors take measurements and then report them to the cloud (Mainflux). Time-series databases are particularly adapted for telemetry data and allow fast complex queries on this type of data. Mainflux uses InfluxDB - open source time-series database written in Go.

Complex Event Processing Engine

Complex Event Processing (CEP) is a method of tracking and analyzing (processing) streams of information (data) about things that happen (events), and deriving a conclusion from them. A Wikipedia example is a good read on the subject.

Mainflux platform integrates Kapacitor, an source framework for processing, monitoring, and alerting on time series data. This way system designers can detect pattern and anomalies on the data and trigger appropriate events or alarms.