Azure Stream Analytics anomaly detection on the edge

Back in 2018, the Azure Stream Analytics team announced Anomaly detection for Azure Stream Analytics. And, it was also supported on the Azure IoT Edge. In November 2018, I was allowed to demonstrate this at the SPS IPC Drives in Nuremberg:

Since then, anomaly detection has become a first citizen of Azure Stream Analytics.

Azure Stream Analytics Anomaly Detection is able to ‘automatically’ detect spikes, dips, and trends in a stream of values. This is based on math and all you need to do is to specify how many values you expect and how sensitive the detection must be. It is in fact Machine Learning, in the end. So it is a prediction with a certain certainty…

And it’s just part of the Stream Analytics query language. So on the edge, we can deploy a Stream Analytics module (the engine of stream analytics). This is a fixed module from Microsoft.

All you have to do is feeding it a query, inputs, outputs and, user-defined functions if available:

We can define all this in the cloud, inside a stream analytics job and we can even test it. Those parts are then packed as a blob and put in blob storage. The Stream Analytics job can then download it and run it.

The inputs and outputs of the Stream Analytics job can be attached to the normal Azure IoT Edge routing mechanism.

Let’s see how this is set up:

Doorgaan met het lezen van “Azure Stream Analytics anomaly detection on the edge”

Using Influx database and Grafana on the Azure IoT Edge

Over the last couple of years, in this blog, multiple databases are demonstrated which can be deployed on the Azure IoT Edge:

Persisting incoming telemetry in a local database is useful for multiple purposes. One of them is creating a custom dashboard eg. written in Blazor.

In this blog, we explore how to deploy the popular InfluxDB. This open-source time-series database is specialized in Internet of Things usage. And on top of that, let’s explore how Grafana can be deployed on the edge too. Grafana is an open source analytics and interactive visualization web application.

We see how it can be connected to the Influx database:

As you see here, we need a custom Azure IoT Edge module (called ‘writer’) that is capable of writing incoming telemetry to the Influx database. There, the telemetry is picked up and displayed by Grafana.

Let’s see how this works.

Doorgaan met het lezen van “Using Influx database and Grafana on the Azure IoT Edge”

Azure IoT Edge module metrics in action

We are familiar with the Azure IoT Hub metrics which are offered. The Azure cloud tells us eg. how many messages are received or the number of devices that are connected.

If we look at Azure IoT Edge, you had to collect your own made metrics in the past.

Because IoT Edge modules are Docker containers and therefore sandboxed, you had to rely on the (third-party) logic to capture Host metrics. Regarding metrics about the edge agent and hub, these were not available.

Until now.

With the most recent IoT Edge runtimes, agent, and hub, we have access to Edge metrics.

Both the Agent and Hub module expose the metrics over HTTP endpoints:

Within the Moby runtime, port 9600 is exposed on both individual modules. Outside the runtime, we have to assign individual host ports to prevent using the same host port.

Let’s see how this looks like and how we can harvest metrics in a custom container.

Doorgaan met het lezen van “Azure IoT Edge module metrics in action”

Using a Weidmueller UC 20 Controller as Azure IoT Edge child device

Azure IoT Edge is a powerful solution for your edge computing needs. It can collect telemetry, make local decisions, and send data to the cloud. This works great if an internet connection is available. If the connection is temporarily broken, everything still works. The telemetry is temporarily persisted so no data is lost.

An edge gateway can also act as a transparent gateway:

Here, child devices are made part of the local routing mechanism of the edge. The child devices are configured to send their telemetry to the edge device. From there, the same telemetry is sent to the cloud as if it’s sent by the child device itself.

The main advantages are:

  1. If no internet connection is available, the child telemetry is stored on the edge until the connection is restored. The child devices have no notion of the edge gateway, hence ‘transparent’
  2. The logic running on the edge is able to access the telemetry coming from child devices so this can be used and combined with other data to take local decisions

This architecture is also known as downstream devices.

I already wrote a blog on this topic previously. In there, some test apps stole the show.

Now, let’s see this in action with an actual industrial device. We also check out sending telemetry back:

We will be working with a Weidmueller UC20, an automation controller.

Doorgaan met het lezen van “Using a Weidmueller UC 20 Controller as Azure IoT Edge child device”

Connecting child devices to the Azure IoT transparent Edge gateway

Getting started with Azure IoT Edge is easy. Microsoft offers quite some tutorials for several operating systems for setting up an edge gateway.

Once you have created your first IoT edge solution and played with it, you discover Azure IoT Edge takes a bit more time to master.

In real-life IoT is hard, though…

This is because there are more moving parts like security, provisioning, managing, monitoring, etc.

For example, take a look at the ‘iotedge check’ output on your edge device:

This feature of the iotedge runtime makes it possible to check how well your runtime is hardened against common scenarios where something can fail (eg. running out of disk space due to extensive logging or firewall blockades for certain protocols).

In this case, a message is shown which indicates the runtime is using a development (x509) certificate which will expire within ninety days. Communication between the edge modules will stop after that date. A reboot/restart of the runtime is needed to get the runtime running again for another ninety days.

What is the purpose of this certificate and why do we need this to be fixed?

As seen in the documentation:

IoT Edge certificates are used by the modules and downstream IoT devices to verify the identity and legitimacy of the IoT Edge hub runtime module

So, apart from the secure connection with the cloud (either with a symmetric key, x509 certificate, or a TPM endorsement), this certificate is used to secure the communication between modules and possible edge devices. If the certificate expires, edge communication comes to a hold.

Let’s check out how to ruggedize the communication.

Doorgaan met het lezen van “Connecting child devices to the Azure IoT transparent Edge gateway”

Deploy Azure IoT Edge deployment manifest programmatically

Azure IoT Edge is based on the concept of modules. A module is a container holding some logic executed on the edge device. These containers are actual Docker containers.

These can both be generic containers like a NodeJS that you have produced yourself, an open-source container, or a commercial container. In can also be a container supporting Azure IoT Edge module twins and the routing between modules using one of the Azure IoT Edge SDKs.

Anyway, the modules have to be deployed at one point in time.

By default, Azure IoT Edge devices are constructed with two basic modules registered, the edgeAgent (which is responsible for life-and-death of other modules) and the edgeHub (for enabling message routing between modules and the local gateway towards the cloud):

With life-or-death of other modules I mean the EdgeAgent is responsible for keeping the module configuration on the Azure IoT Edge device in sync with the registration and configuration in the IoT Hub device registration.

For this purpose, the Edge Agent is keen on receiving the so-called ‘deployment manifest‘.

Each time the configuration of an edge device registration in the IoT Hub changes, a new version of the deployment manifest is offered to the Edge Agent. It contains both the module descriptions and their configuration and a description of the message routing on the edge.

The Edge Agent then picks up the deployment manifest and checks for changes with the last manifest it received. If there are any configuration changes, or modules added or modules deleted, the edgeAgent will start the process of synchronizing the deployment.

If you check the documentation, three ways of altering the IoT Edge configuration (and thus deploying a new deployment manifest) are documented:

  1. Command Line Interface (CLI)
  2. The Azure portal
  3. Visual Studio Code

Notice these deployments are effectuated by hand.

For those seeking a CI/CD solution two other ways are offered:

  1. Azure DevOps
  2. Jenkins

These are advised if you want to automate the deployment in a CI/CD pipeline.

If you prefer to do everything by programming source code, you can deploy your manifest using REST calls.

Let’s see how that is done.

Doorgaan met het lezen van “Deploy Azure IoT Edge deployment manifest programmatically”

Using CrateDB on Azure IoT Edge

During the SPS IPC Drives of 2018, I was introduced to the team of CrateDB.

They offer this blazing fast database:

CrateDB is a distributed SQL database built on a NoSQL foundation. It is familiar to use, simple to scale, and versatile for handling any type of structured or unstructured data with real-time query performance.

It’s always nice being able to choose from several services like databases. So I checked out how to develop a simple application and Azure IoT Edge module against Crate if running in a container.

In this blog, we see how we can use the CrateDB in Azure IoT Edge.

Doorgaan met het lezen van “Using CrateDB on Azure IoT Edge”

Adding local persisted state to IoT Edge modules using Module twin

Each Azure IoT Edge module, deployed to a device, has its own Module twin.

A Module twin is the same concept as a Device twin for an Azure IoT Device, it stores state information including metadata, configurations, and conditions.

A Module twin is essentially a JSON document which lives both in the cloud (in the IoT Hub) and on the device and is kept in sync when communication between device and cloud is possible:

In the IoT Hub, the tags are writable and readable. These can be used to identify a specific device with an alternative key and/or to filter subsets of devices.

Also in the cloud, the desired properties can be written with updated values. These (updated) values (eg. properties or settings) are picked up by the device when it is connected. So it could take days or weeks for the updated desired property to be picked up because the device is offline in the meanwhile.

But the desired properties are patient…

Once the updated values of changed desired properties are arriving at a device, a notification method on the device is triggered to handle them.

As a good citizen, an IoT Edge module should report back to the cloud how it is updated by the desired properties. This is done using the reported properties in the Module twin.

This closes the loop for the administrator. I can publish a desired property change for one or more devices. And after a while, the reported properties can be checked to see which devices have picked them up and which devices need some attention.

Do you notice that it’s also possible to read reported properties, on the module side?

Write data, read data… that is enough to persist data on the edge, isn’t it?

Let’s see how we can use this for persisting local state.

Doorgaan met het lezen van “Adding local persisted state to IoT Edge modules using Module twin”

How to deploy and access MySql using Azure IoT Edge

In my previous blog, I showed how regular Docker containers can be rolled out using Azure IoT Edge.

But what about databases, can these be deployed too?

Yes, I showed how to deploy and connect to SQL Server in the past and it works very well if you like SQL Server.

But what about MySql, can we connect to this database too?

Many of the world’s largest and fastest-growing organizations including Facebook, Google, Adobe, Alcatel Lucent, and Zappos rely on MySQL to save time and money powering their high-volume Web sites, business-critical systems, and packaged software.

https://www.mysql.com/why-mysql/

MySql is available as an official Docker container which is needed for this exercise:

So let’s give it a try.

Doorgaan met het lezen van “How to deploy and access MySql using Azure IoT Edge”

Turn Jetson Nano vision into insights

Recently I got my hands on an Nvidia Jetson Nano toolkit. This wonderful device runs Ubuntu and is capable to support Azure IoT Edge:

The heart of this device, just beneath the cooling sink, is this board with a 128-core Maxwell GPU:

That is a lot of GPU compute power for just 99 dollars.

I found this hands-on lab from Paul DeCarlo. This simple to follow lab brings vision and object recognition to the cloud using Azure IoT Edge.

Let’s see how Azure Stream Analytics turns object recognition into insights in the cloud.

Doorgaan met het lezen van “Turn Jetson Nano vision into insights”