Posted on 1 Comment

Introduction to Azure IoT Hub and Related Services SDKs

In February 2021, I wrote an article exploring the differences between Azure IoT Hub Devices and Modules. It was well-received and remains one of my most-visited blog posts. Now, with more experience in device and Edge development, I’d like to revisit the topic, but expand it to include other types of Azure IoT SDKs. There have been changes to the Azure IoT Hub device landscape, and I’m better equipped to provide useful information about the various SDKs available.

Microsoft has these divided into three basic SDK types.

  • Device SDKs
  • Service SDKs
  • Management SDKs

To make this as simple as possible, I like to think of the SDKs as serving these purposes:

  • Device – this code runs on the device either as bare metal or in a container. It represents either a leaf device or an Edge gateway. If it connects to IoT to feed it data, it needs this SDK.
  • Service – this code enables me to manage my devices with updates or other forms of communication using IoT Hub. This involves administrative tasks, all of which are focused on using the IoT Hub API to interact with the devices.
  • Management is more complex, since these are SDKs designed to manage your IoT Hub or Hubs. I could use this to monitor my IoT Hub, create or delete Hub instances, and keep track of my shared access policies.

This document focuses on the SDKs and their updates to match the latest versions of Azure IoT services. Use this as a starting point for further research. If you spot any mistakes or think I’ve missed something important, please let me know in the comments. I’m always open to feedback from my readers. I’m well aware that I make mistakes, and I’m always learning.

What are Azure IoT Hub Device SDKs?

Azure IoT Hub Device SDKs provide APIs and libraries that allow developers to create applications for IoT devices and connect them to Azure IoT Hub. These SDKs support a wide range of programming languages and platforms, and offer unique sets of features tailored to the language and platform. Common use cases include sending telemetry data, receiving commands, connecting devices using various protocols, authenticating devices, handling messaging, managing device twins, and receiving notifications.

A small code example in Python

import os
from azure.iot.device import IoTHubDeviceClient
# Retrieve the connection string for the device from an environment variable
conn_str = os.getenv("IOTHUB_DEVICE_CONNECTION_STRING")
# Create an IoT Hub client
client = IoTHubDeviceClient.create_from_connection_string(conn_str)
# Send a message to IoT Hub
message = "Hello, I am a device using IoT Hub!"
client.send_message(message)
print("Sent message: {}".format(message))
# Disconnect the client
client.disconnect()

This code imports the necessary modules from the Azure IoT Hub Device SDK and creates an IoT Hub client. It then sends a message to IoT Hub and disconnects the client when finished.

To use this code, you must have the Azure IoT Hub Device SDK installed and have a connection string for a device registered with IoT Hub.

Unlike many vendor devices, the SDKs present you with the opportunity to create your own IoT devices. You may have heard of IoT Edge, so let’s address what that is now.

What is Azure IoT Edge?

Azure IoT Edge is a fully managed service that enables developers to deploy cloud intelligence directly onto IoT devices. It allows them to build, deploy, and manage applications that run on edge devices and leverage cloud-based services and data to perform tasks such as data processing, analytics, machine learning, and more.

Azure IoT Edge consists of three main components:

  1. Edge Modules: Small, lightweight pieces of code that run on edge devices and perform specific tasks. Edge modules can be written in a variety of programming languages, including C#, Java, Python, and more.
  2. IoT Edge Runtime: A lightweight container that runs on edge devices and manages the lifecycle of edge modules. The IoT Edge runtime can be installed on a wide range of operating systems and devices, including Windows, Linux, and various embedded platforms.
  3. Azure IoT Hub: A cloud-based service that acts as the central hub for communication between edge devices and the cloud. IoT Hub provides a secure and scalable platform for managing devices, sending commands and notifications to devices, and receiving telemetry data from devices.

Azure IoT Edge enables developers to create and deploy intelligent edge solutions that bring the power of the cloud to the edge of the network. These solutions can perform tasks such as data processing, analytics, machine learning, and more on edge devices, reducing the amount of data that needs to be sent to the cloud and enabling fast decision-making and action. Azure IoT Edge is especially useful for scenarios where latency or connectivity issues make it difficult to rely solely on the cloud for data processing and analysis.

A small code example

import os
from azure.iot.edge.module_client import ModuleClient
# Create a module client
client = ModuleClient.create_from_edge_environment()
# Connect the module client to IoT Hub
client.connect()
# Send a message to IoT Hub
message = "Hello from IoT Edge!"
client.send_message_to_output("channel1", message)
print("Sent message: {}".format(message))
# Disconnect the module client
client.disconnect()

This code imports the necessary modules from the Azure IoT Edge Python SDK and creates a module client. It then uses the module client to connect to IoT Hub, send a message, and disconnect.

To use this code, you must have the Azure IoT Edge Python SDK installed and an IoT Edge runtime running on your device. Additionally, an IoT Edge module must be deployed to the device with an output binding named “channel1”.

These are basic approaches to the device and modules, but I wanted to give you an idea of how easy they can be to use. Setting up IoT Edge for development involves some complexity, but the ability to run containerized cloud solutions at the edge makes it worthwhile.

What about IoT Central?

Many of the concepts covered in this article are also true or will work with IoT Central. For this article, I’m focusing on IoT Hub. I will have a future article dedicated to IoT Central and it’s SDKs and APIs.

Azure IoT Hub Device SDKs

Azure IoT Hub Device SDKs are software development kits (SDKs) that enable developers to create applications that run on IoT devices and connect them to Azure IoT Hub. These SDKs provide a set of APIs and libraries that allow devices to perform basic and complex IoT device to cloud communications and commands.

Azure IoT Hub supports device SDKs for a wide range of programming languages and platforms, including C, C#, Java, JavaScript, Python, and a few that are platform specific. Each device SDK provides a set of APIs and libraries tailored to the programming language and platform, making it easy for developers to create applications that interact with Azure IoT Hub.

Some common use cases for Azure IoT Hub Device SDKs include:

  • Sending telemetry data from devices to IoT Hub
  • Receiving commands from IoT Hub and executing them on devices
  • Connecting devices to IoT Hub using various protocols, such as MQTT, AMQP, HTTP, and more
  • Authenticating devices with IoT Hub using various authentication mechanisms, such as shared access signatures (SAS) tokens and X.509 certificates
  • Handling device-to-cloud and cloud-to-device messaging in a reliable and secure manner
  • Managing device twins, which are JSON documents that store metadata about devices in IoT Hub
  • Receiving notifications about device connections, disconnections, and other events from IoT Hub

Overview of the different device SDKs available

  • C: The C Device SDK is a lightweight, portable library that enables C-based devices to connect to Azure IoT Hub and interact with the cloud. It supports various protocols, including MQTT, AMQP, HTTP, and more, and provides APIs for tasks such as sending telemetry data, receiving commands, and authenticating with the IoT Hub.
#include <stdio.h>
#include <stdlib.h>
#include "iothub_client.h"
#include "iothub_message.h"
#include "azure_c_shared_utility/threadapi.h"
#include "azure_c_shared_utility/crt_abstractions.h"
#include "azure_c_shared_utility/platform.h"
int main(void)
{
    // Retrieve the connection string for the device from an environment variable
    char* conn_str = getenv("IOTHUB_DEVICE_CONNECTION_STRING");
    // Create an IoT Hub client
    IOTHUB_CLIENT_HANDLE client = IoTHubClient_CreateFromConnectionString(conn_str);
    if (client == NULL)
    {
        (void)printf("ERROR: iothub_client_create failed\\n");
    }
    else
    {
        // Send a message to IoT Hub
        IOTHUB_MESSAGE_HANDLE message = IoTHubMessage_CreateFromString("Hello, Azure IoT Hub!");
        if (IoTHubClient_SendEventAsync(client, message, NULL, NULL) != IOTHUB_CLIENT_OK)
        {
            (void)printf("ERROR: IoTHubClient_SendEventAsync failed\\n");
        }
        else
        {
            (void)printf("Sent message: Hello, Azure IoT Hub!\\n");
        }
        IoTHubMessage_Destroy(message);
    }
    // Disconnect the client
    IoTHubClient_Destroy(client);
    return 0;
}

This code includes the necessary header files from the Azure IoT Hub C Device SDK and uses them to create an IoT Hub client. It then sends a message to IoT Hub using the client, before disconnecting the client when complete.

To use this code, you must have the Azure IoT Hub C Device SDK installed on your machine and have a connection string for a device registered with IoT Hub.

  • C#: The C# Device SDK is a fully-featured library that enables C#-based devices to connect to Azure IoT Hub and interact with the cloud. It supports various protocols, including MQTT, AMQP, HTTP, and more, and provides APIs for tasks such as sending telemetry data, receiving commands, and authenticating with the IoT Hub. It also includes support for advanced features such as device twins and direct method invocations.
using Microsoft.Azure.Devices.Client;
using System;
using System.Text;
using System.Threading.Tasks;
namespace ConsoleApp
{
    class Program
    {
        static void Main(string[] args)
        {
            // Retrieve the connection string for the device from an environment variable
            string conn_str = Environment.GetEnvironmentVariable("IOTHUB_DEVICE_CONNECTION_STRING");
            // Create an IoT Hub client
            DeviceClient client = DeviceClient.CreateFromConnectionString(conn_str);
            // Send a message to IoT Hub
            string message = "Hello, Azure IoT Hub!";
            byte[] message_bytes = Encoding.UTF8.GetBytes(message);
            Message iot_hub_message = new Message(message_bytes);
            client.SendEventAsync(iot_hub_message).Wait();
            Console.WriteLine("Sent message: {0}", message);
            // Disconnect the client
            client.CloseAsync().Wait();
        }
    }
}

This code imports the necessary namespaces from the Azure IoT Hub C# Device SDK and creates an IoT Hub client. It then sends a message to IoT Hub, before disconnecting the client.

To use this code, you must install the Azure IoT Hub C# Device SDK on your machine and obtain a connection string for a device registered with IoT Hub.

  • Java: The Java Device SDK is a fully-featured library that enables Java-based devices to connect to Azure IoT Hub and interact with the cloud. It supports various protocols, including MQTT, AMQP, HTTP, and more, and provides APIs for tasks such as sending telemetry data, receiving commands, and authenticating with the IoT Hub. It also includes support for advanced features such as device twins and direct method invocations.
import com.microsoft.azure.sdk.iot.device.DeviceClient;
import com.microsoft.azure.sdk.iot.device.IotHubClientProtocol;
import com.microsoft.azure.sdk.iot.device.Message;
public class Main
{
    public static void main(String[] args) throws Exception
    {
        // Retrieve the connection string for the device from an environment variable
        String conn_str = System.getenv("IOTHUB_DEVICE_CONNECTION_STRING");
        // Create an IoT Hub client
        IotHubClientProtocol protocol = IotHubClientProtocol.AMQPS;
        DeviceClient client = new DeviceClient(conn_str, protocol);
        client.open();
        // Send a message to IoT Hub
        String message = "Hello!";
        Message iot_hub_message = new Message(message);
        client.sendEventAsync(iot_hub_message);
        System.out.println("Sent message: " + message);
        // Disconnect the client
        client.close();
    }
}

This code includes the necessary namespaces from the Azure IoT Hub Java Device SDK and uses them to create an IoT Hub client. It then uses the client to connect to IoT Hub, send a message to IoT Hub, and disconnect the client when it’s finished.

  • JavaScript: The JavaScript Device SDK is a fully-featured library that enables JavaScript-based devices to connect to Azure IoT Hub and interact with the cloud. It supports various protocols, including MQTT, AMQP, HTTP, and more, and provides APIs for tasks such as sending telemetry data, receiving commands, and authenticating with the IoT Hub. It also includes support for advanced features such as device twins and direct method invocations.
const { Client } = require('azure-iot-device');
// Retrieve the connection string for the device from an environment variable
const conn_str = process.env.IOTHUB_DEVICE_CONNECTION_STRING;
// Create an IoT Hub client
const client = Client.fromConnectionString(conn_str, Client.IotHubTransport);
// Connect the client
client.open((err) => {
    if (err) {
        console.error('Error opening the client: ' + err.message);
    } else {
        // Send a message to IoT Hub
        const message = new Message('Hello, Azure IoT Hub!');
        client.sendEvent(message, (send_err) => {
            if (send_err) {
                console.error('Error sending the message: ' + send_err.message);
            } else {
                console.log('Sent message: ' + message.getData());
            }
        });
    }
});

This code imports the necessary modules from the Azure IoT Hub JavaScript Device SDK, creating an IoT Hub client. It then connects to IoT Hub and sends a message.

  • Python: The Python Device SDK is a fully-featured library that enables Python-based devices to connect to Azure IoT Hub and interact with the cloud. It supports various protocols, including MQTT, AMQP, HTTP, and more, and provides APIs for tasks such as sending telemetry data, receiving commands, and authenticating with the IoT Hub. It also includes support for advanced features such as device twins and direct method invocations.
import os
from azure.iot.edge.module_client import ModuleClient
# Create a module client
client = ModuleClient.create_from_edge_environment()
# Connect the module client to IoT Hub
client.connect()
# Send a message to IoT Hub
message = "Hello from IoT Edge!"
client.send_message_to_output("output1", message)
print("Sent message: {}".format(message))
# Disconnect the module client
client.disconnect()

Device SDKs for specific programming languages and platforms

Azure RTOS

Azure RTOS (Real-Time Operating System) is a suite of RTOS kernels and middleware components optimized for use with small, resource-constrained devices running on Arm Cortex-M microcontrollers. It provides developers with a robust and scalable platform for building IoT solutions that require real-time performance, low power consumption, and a small footprint.

The Azure RTOS middleware is a set of software components that provide additional functionality and support for developing IoT solutions. These components include:

  • Networking libraries and protocols such as TCP/IP, HTTP, HTTPS, and MQTT, which allow devices to connect to the cloud and other devices over the network.
  • Security libraries and protocols such as SSL/TLS, X.509 certificates, and secure boot, which allow devices to authenticate and encrypt communication with the cloud and other devices.
  • A file system library that allows devices to store and retrieve data on external storage devices such as SD cards.
  • The ThreadX RTOS kernel, which provides a lightweight, scalable, and reliable platform for building real-time applications on Arm Cortex-M microcontrollers.

Azure RTOS is available for a variety of Arm Cortex-M microcontrollers, including those from STMicro.

FreeRTOS

FreeRTOS is an open-source real-time operating system (RTOS) for building small, resource-constrained devices for the Internet of Things (IoT). It is designed to be lightweight, scalable, and reliable, offering a range of features and services that are beneficial for constructing IoT solutions, including:

  • Task scheduling and management
  • Memory management
  • Timers and software timers
  • Inter-task communication and synchronization
  • Networking libraries and protocols, such as TCP/IP, HTTP, and MQTT
  • Security libraries and protocols, such as SSL/TLS, X.509 certificates, and secure boot
  • File system libraries
  • Device drivers and middleware components for various hardware peripherals

FreeRTOS is available for a wide range of microcontrollers and platforms, including those from Atmel, NXP, and STMicroelectronics. It has a large community of developers and users, and is regularly updated and improved.

Azure IoT provides libraries and tools to connect FreeRTOS-based devices to its services, such as the IoT Hub, IoT Central, and IoT Edge. This enables developers to create IoT solutions that benefit from the scalability, security, and reliability of the Azure cloud.

Bare Metal (Azure SDK for Embedded C)

The Azure SDK for Embedded C is a software development kit (SDK) that enables developers to build IoT solutions using the C programming language and Microsoft Azure cloud services. It provides libraries, tools, and documentation to easily connect C-based devices to Azure IoT services such as IoT Hub, IoT Central, and IoT Edge, and construct IoT solutions that benefit from the scalability, security, and reliability of the Azure cloud.

The SDK supports a variety of microcontrollers and platforms from manufacturers like Atmel, NXP, and STMicroelectronics. It offers support for protocols and features like MQTT, AMQP, HTTP, device twins, and direct method invocations, and provides APIs for tasks like sending telemetry data, receiving commands, and authenticating with Azure IoT services.

The Azure SDK for Embedded C is open source and constantly updated and improved by a community of developers and users. It is lightweight, portable, and easy to use, and can be integrated into various development environments and toolchains.

Connecting devices to Azure IoT Hub using the device SDKs

To connect a device to Azure IoT Hub using a device SDK, you need to:

  1. Install the device SDK on your device or development machine. The device SDK provides the necessary libraries and tools to build IoT solutions that can connect to Azure IoT Hub.
  2. Register your device with Azure IoT Hub. This step involves creating a device identity in IoT Hub and obtaining a connection string that uniquely identifies your device. The connection string includes the device’s ID, hub name, and authentication key, and is used to authenticate the device with IoT Hub when it connects.
  3. Use the device SDK to create an IoT Hub client on your device. The IoT Hub client is responsible for establishing and maintaining a connection with IoT Hub, as well as sending and receiving messages.
  4. Use the IoT Hub client to connect to IoT Hub. This typically involves providing the client with the connection string and specifying the protocol to use (such as MQTT or AMQP). The client will then establish a connection with IoT Hub and authenticate using the information in the connection string.
  5. Use the IoT Hub client to send messages to IoT Hub and receive messages from IoT Hub. The device SDK provides APIs for tasks such as sending telemetry data, receiving commands, and interacting with device twins and direct methods.

This article provided a basic overview of the device SDKs for the languages and platforms supported for Azure IoT Hub. The example code was meant to give a glimpse of how it works, but not of real world workloads. In most cases, you’ll use the local device libraries to connect to sensors and collect data to send to IoT Hub. This usually requires developing an asynchronous listener to capture the telemetry data and send it in a message to IoT Hub. This functionality is beyond the scope of this article, but I am working on a newer set of Agriculture code for one of my devices. I will post it here soon, which will provide a more complete solution to device development on a Raspberry Pi.

Azure IoT Hub Service and Management SDKs

The Azure IoT Hub Service SDKs are a set of software development kits (SDKs) that enable developers to build applications that interact with Azure IoT Hub. They provide APIs and libraries in various programming languages and platforms, allowing developers to create, manage, and interact with devices and other resources in IoT Hub. The SDKs are available for .NET, Java, Node.js, Python, and Go, and offer functions such as sending and receiving messages, creating and updating devices, managing device twins and direct methods, and monitoring device health and status.

Overview of the different service SDKs available

The Azure IoT Hub Service SDKs are a set of software development kits (SDKs) that enable developers to build applications that interact with Azure IoT Hub. They provide APIs and libraries in various programming languages and platforms, allowing developers to create, manage, and interact with devices and other resources in IoT Hub. From the choices, it’s clear that these SDKs are designed to supplement or amplify the capabilities of IoT Hub.

These are just a few of the possible uses for the Service SDK:

  • Sending and receiving messages to and from devices
  • Creating, updating, and deleting devices in IoT Hub
  • Managing device twins and direct methods
  • Monitoring the health and status of devices and other resources in IoT Hub

A couple of specific use cases I can imagine are:

  • An integration with an application or an enterprise system that is not available through the standard IoT Hub integration channels.
  • Updating device digital twins is a good use of the SDK, especially for automated processes
  • Device Registry is particularly useful when dealing with a large number of devices. Automating the process is highly recommended. I will go into more detail about this in a future blog post.

The Azure IoT Hub Service SDKs are available for a variety of programming languages and platforms, such as:

  • .NET: The Azure IoT Hub .NET Service SDK
  • Java: The Azure IoT Hub Java Service SDK
  • Node.js: The Azure IoT Hub Node.js Service SDK
  • Python: The Azure IoT Hub Python Service SDK
  • Go: The Azure IoT Hub Go Service SDK

Service SDKs for specific programming languages and platforms

  • .NET: The Azure IoT Hub .NET Service SDK

This is likely the library that most traditional Microsoft developers will gravitate toward. It’s definitely a well-developed, highly supported library. This library has been migrated to

https://github.com/Azure/azure-iot-sdk-csharp

The Azure IoT SDK for C# is a software development kit that enables developers to build IoT solutions using C# and Microsoft Azure cloud services. It provides libraries, tools, and documentation to connect C#-based devices and applications to Azure IoT services, and includes support for a variety of microcontrollers and protocols. The SDK is open source and designed to be lightweight, portable, and easy to use.

I’m not including code sample here, because they tend to be a bit larger. However, I think it’s just as important to work with the service SDKs as the device SDKs. You’ll find they make your administrative work easier.

  • Java: The Azure IoT Hub Java Service SDK

The Java Service SDK offers many of the same functions as the .Net library. It includes the following samples to complete tasks related to device management, data processing and analytics, and integration and orchestration:

  • Device management: Create, update, and delete devices in IoT Hub, manage device twins, and use direct methods.
  • Data processing and analytics: Receive telemetry data from devices in IoT Hub, process and analyze the data, and trigger alerts or create reports.
  • Integration and orchestration: Integrate IoT Hub with other systems and services, such as enterprise applications or cloud platforms, and build complex workflows and processes that span multiple devices and services.

azure-iot-sdk-java/service/iot-service-samples at main · Azure/azure-iot-sdk-java

  • JavaScript: Azure SDK for JS

The IoT Hub Service SDK for Node.js doesn’t appear to have code for the IoT Hub service, yet. However, the JavaScript is still available. It has many of the same functionality as the other SDKs. One thing to note is that many of these are in TypeScript and it appears that there are more samples available here. So if you’re looking for a functionality that doesn’t exists in the other samples, you may want to search through these code examples:

azure-sdk-for-js/sdk/iothub/arm-iothub/samples-dev at main · Azure/azure-sdk-for-js

  • Python: The Azure IoT Hub Python Service SDK

The Azure IoT Hub Python library is here:

https://github.com/Azure/azure-iot-hub-python

It has many of the same functionality as the other library. I would say that the Client library is a bit more robust than the library for IoT Hub, but most of the functionality you’ll want exists. There are also plenty of examples to get you started. And one of the things I love about Python is how much you can accomplish with so little code:

# -------------------------------------------------------------------------
# Copyright (c) Microsoft Corporation. All rights reserved.
# Licensed under the MIT License. See License.txt in the project root for
# license information.
# --------------------------------------------------------------------------
import os
import msrest
from azure.iot.hub import DigitalTwinClient
iothub_connection_str = os.getenv("IOTHUB_CONNECTION_STRING")
device_id = os.getenv("IOTHUB_DEVICE_ID")
try:
    # Create DigitalTwinClient
    digital_twin_client = DigitalTwinClient.from_connection_string(iothub_connection_str)
    # Get digital twin and retrieve the modelId from it
    digital_twin = digital_twin_client.get_digital_twin(device_id)
    if digital_twin:
        print(digital_twin)
        print("Model Id: " + digital_twin["$metadata"]["$model"])
    else:
        print("No digital_twin found")
except msrest.exceptions.HttpOperationError as ex:
    print("HttpOperationError error {0}".format(ex.response.text))
except Exception as exc:
    print("Unexpected error {0}".format(exc))
except KeyboardInterrupt:
    print("{} stopped".format(__file__))
finally:
    print("{} finished".format(__file__))
  • Go: Azure SDK for Go

To my knowledge, there is no official Microsoft sponsored IoT Hub or Client library for GO. At the time of this writing, the services supported are:

  • Azure Blob Storage
  • Azure Functions
  • Azure Container Registry
  • Azure Container Instance
  • Azure Kubernetes Service
  • Azure Virtual Machines
  • Azure Key Vault
  • And Azure Cognitive Service

However, the success of Go as a Cloud Native language has prompted an Azure Go SDK. There is a version that appears to have been created here:

https://github.com/amenzhinsky/iothub

There is code for Device and Service here with very few samples, but it’s probably enough to get someone started:

package main
import (
	"context"
	"fmt"
	"log"
	"os"
	"github.com/amenzhinsky/iothub/iotservice"
)
func main() {
	c, err := iotservice.NewFromConnectionString(
		os.Getenv("IOTHUB_SERVICE_CONNECTION_STRING"),
	)
	if err != nil {
		log.Fatal(err)
	}
	// subscribe to device-to-cloud events
	log.Fatal(c.SubscribeEvents(context.Background(), func(msg *iotservice.Event) error {
		fmt.Printf("%q sends %q", msg.ConnectionDeviceID, msg.Payload)
		return nil
	}))
}

Using the management SDKs to communicate with devices and manage IoT Hub resources

Here, I want to discuss some unique ways to use the Azure IoT Hub Management SDKs to work with IoT Hub. The SDKs provide APIs and libraries that enable developers to manage and operate IoT Hub, such as creating and deleting instances, setting and querying properties and quotas, managing shared access policies, monitoring usage and diagnostics, and performing maintenance tasks like repairing or backing up IoT Hub. The SDKs are available for .NET, Python, and Node.js, and can be used on Windows, macOS, and Linux.

I don’t think the average IoT developer will be too concerned with these SDKs. However, if you work in an organization with multiple IoT hubs and millions of devices, these packages could be useful. Additionally, if you want to build products that use IoT Hub as a base service, then you should definitely look into these SDKs.

  • Azure SDK for .Net IoT Management

To get down to more detail, because I think it’s important to look at the detail for this particular SDK, here’s what’s delivered in the primary IoT Hub client for management. This piece of code is what I’m reviewing:

azure-sdk-for-net/IotHubClient.cs at main · Azure/azure-sdk-for-net

The code is a part of the Azure IoT Hub .NET Management SDK, which is a set of libraries and tools for building .NET applications that manage and operate Azure IoT Hub.

The file, IotHubClient.cs, contains the implementation of the IotHubClient class, which is a client object that provides a set of methods and properties for interacting with the Azure IoT Hub service. The IotHubClient class is part of the generated code for the Azure Management Libraries for .NET, which is a set of libraries that provide a consistent, easy-to-use, and high-level API for accessing Azure cloud services.

The IotHubClient class is used to perform various tasks related to managing and operating an IoT Hub instance, such as:

  • Creating and deleting IoT Hub instances
  • Setting and querying IoT Hub properties and quotas
  • Managing IoT Hub shared access policies
  • Monitoring IoT Hub usage and diagnostics
  • Performing maintenance tasks such as repairing or backing up IoT Hub

The IotHubClient class exposes a set of methods that correspond to the different operations that can be performed on an IoT Hub instance. For example, the IotHubClient.CreateOrUpdateAsync method is used to create or update an IoT Hub instance, and the IotHubClient.GetAsync method is used to retrieve the properties of an IoT Hub instance.

  • Azure SDK for Java – Azure Resource Manager IotHub client library for Java

I believe this is a better library than the .Net version. I provides more capabilities and samples.

azure-sdk-for-java/sdk/iothub/azure-resourcemanager-iothub at main · Azure/azure-sdk-for-java

The Java library has many of the same features as other libraries. It is based on the Azure Resource Manager Java library, so if you are already familiar with it, using the IoT Hub Management Library should be straightforward.

  • Azure iotHub client library for JavaScript

This is the same library as the Service library, which makes sense. It explains why the Service library seems larger than the other service libraries. This is also built on top of the Azure Resource Management.

  • Azure SDK for Python – Azure Management IoT Hbu

This library is a bit more like the .Net library. You enter with an IoT Hub Client and access you capabilities that way. It offers most of the same capabilities of the other libraries.

Overall, these libraries offer similar capabilities. Java and JavaScript have had more development, but the .Net and Python versions are still useful. Additionally, the API provides many management capabilities. If the SDKs don’t meet your needs, you can use Azure Resource Manager to manage IoT Hub.

Azure IoT Services SDKs

Azure IoT SDKs provide a range of tools and services for building secure, connected, and location-aware IoT applications and solutions. This section will cover the basics of these products.

Azure Maps, Azure Sphere, Azure Digital Twins, Azure Object Anchors, and Azure Remote Rendering are all included in the Azure IoT resources. Each of these offers unique features and capabilities to enable the development of IoT applications and solutions.

Overview of the Azure IoT services SDKs available

Azure Maps

Azure Maps is a cloud-based mapping and location platform that provides a range of tools and services for building location-based applications and solutions. It is part of the Azure IoT resources, as it can be used to build location-aware IoT applications and solutions that incorporate geospatial data and functionality.

Some of its key features and capabilities include:

  1. Map rendering: Azure Maps offers 2D and 3D maps, street maps, satellite imagery, and terrain maps, which can be rendered and displayed in web-based, mobile, and embedded formats.
  2. Geocoding and reverse geocoding: Convert addresses and location coordinates into geographic locations, and vice versa.
  3. Routing and navigation: Calculate routes and directions between two or more locations.
  4. Location services: Geofencing, location search, and real-time traffic data for building location-based applications.

Overall, Azure Maps is a powerful and flexible platform for building location-based applications and solutions, especially for IoT scenarios.

Azure maps provides four separate SDKs to help developers:

  • REST SDK
  • Web SDK (JavaScript)
  • Android SDK (Java or Kotlin)
  • iOS (Swift)

Azure Maps Documentation

Azure Sphere

Azure Sphere is a secure and connected microcontroller platform designed for building Internet of Things (IoT) applications and solutions. It is part of the Azure IoT resources, providing a range of tools and technologies to build and deploy secure, connected IoT devices.

Key features and capabilities of Azure Sphere include:

  1. Security: Azure Sphere is designed to provide a high level of security for IoT devices. It features a custom-built Linux operating system and a hardware-based security module that provides secure boot, trusted execution, and hardware-level isolation.
  2. Connectivity: Azure Sphere supports various connectivity options, including Wi-Fi and cellular, allowing devices to connect to the internet and communicate with other devices and systems.
  3. Development tools: Azure Sphere includes a software development kit (SDK), libraries and APIs, and integration with Azure IoT Hub and other Azure services, making it easier to build and deploy IoT applications and solutions.

Overall, Azure Sphere is an excellent platform for building and deploying secure, connected IoT devices, especially in scenarios where security and connectivity are paramount. Azure Sphere comes with a complete development kit. There are two basic SDKs, a Windows and a Linux version. The only supported programming language for Sphere appears to be C, which makes sense considering it’s designed for embedded development.

Digital Twins

Azure Digital Twins is different from the device digital twin discussed in this article. It is a cloud-based platform that enables you to construct digital twin models of physical spaces, systems, and assets. A digital twin is a digital representation of a physical object or environment that reflects its real-world characteristics and behavior.

Azure Digital Twins is part of the Azure IoT resources, providing tools and capabilities to build and deploy IoT applications and solutions that incorporate digital twin models. Key features and capabilities of Azure Digital Twins include:

  1. Data modeling and integration: Create a digital twin model by defining objects and properties that represent physical objects and features in the environment, as well as the relationships between them. Integrate data from external sources, such as sensors, devices, and systems, into the digital twin model.
  2. Data storage and querying: Store and query data within the digital twin model. Use various data types and formats to represent data in the digital twin, and use SQL-like queries to retrieve and analyze the data.
  3. Behaviors and logic: Define behaviors and logic in the digital twin model, using tools such as Azure Functions and Azure Stream Analytics. This enables the digital twin to respond to events and conditions in real-time, and perform actions or calculations based on the data in the digital twin.
  4. Visualization and exploration: Use the Azure Digital Twins portal, Azure Grafana, or the Azure Digital Twins REST API to view and interact with the digital twin.

Overall, Azure Digital Twins is a powerful and flexible platform for creating and managing digital twin models, and enabling a wide range of use cases and scenarios in the IoT space.

Azure Digital Twins comes with control plane APIs, data plane APIs, and SDKs for managing instances and its elements. The SDKs available are for .NET (C#), Java, JavaScript, Python, and Go.

I plan to cover Azure Digital Twins in much greater detail in the future. I’m working on a small book on the subject for Solution Architects. I think it’s one of the most interesting technologies available today. I don’t think we’ve scratched the surface of its potential.

Object Anchors

Azure Object Anchors is a service that allows you to create, manage, and interact with digital representations of physical objects in mixed reality applications. It is included in the Azure IoT resources as it can be used to build IoT applications and solutions with mixed reality features.

Some of the key features and capabilities of Azure Object Anchors include:

  1. Object recognition: Azure Object Anchors can recognize and track physical objects in real-time using machine learning algorithms and computer vision techniques. This enables you to create digital representations of physical objects that can be displayed in mixed reality applications.
  2. Digital twin creation: Azure Object Anchors allows you to create digital twin models of physical objects, which can reflect the real-world characteristics and behavior of the objects. You can define the properties and relationships of the objects in the digital twin model, and integrate data from external sources such as sensors and devices.
  3. Mixed reality integration: Azure Object Anchors can be integrated with mixed reality platforms and tools, such as HoloLens and Unity, allowing you to build mixed reality applications that incorporate the digital twin models created with Azure Object Anchors.

Azure Object Anchors is a powerful platform for building mixed reality applications and solutions that incorporate digital representations of physical objects, particularly in IoT scenarios. Development is built around the Unity game development platform and the Hololens device, though not necessarily restricted to them. The SDKs available are a Conversion SDK for .NET designed to turn existing 3D model assets into Unity Digital Twin objects, as well as Runtime SDKs for Unity and Hololens. If you plan to include Augmented Reality into your IoT solution, Azure Object Anchors is a great option.

Remote Rendering

Azure Remote Rendering is a cloud-based service that enables high-quality 3D graphics and visualization to be rendered in real-time, using the power and scale of the cloud. It is included in the Azure IoT resources because it can be used to build IoT applications and solutions that incorporate 3D graphics and visualization, and that require real-time rendering at scale.

Key features and capabilities of Azure Remote Rendering include:

  1. 3D graphics rendering: Azure Remote Rendering offers a range of tools and technologies for rendering high-quality 3D graphics, such as support for various 3D file formats, realistic lighting and materials, and advanced rendering techniques like ray tracing.
  2. Real-time rendering: Azure Remote Rendering is designed to support real-time rendering of 3D graphics, even at high resolutions and frame rates. This is useful for applications and solutions that need to display dynamic, interactive 3D graphics in real-time.
  3. Cloud-based rendering: Azure Remote Rendering leverages the power and scale of the cloud to enable high-performance rendering of 3D graphics. This is beneficial for applications and solutions that need to support large numbers of users or devices, or that need to process large volumes of data.
  4. Integration with other Azure services: Azure Remote Rendering can be integrated with other Azure services, such as Azure IoT Hub and Azure Stream Analytics, which allows for the building of IoT applications and solutions that incorporate 3D graphics and visualization.

Overall, Azure Remote Rendering is an effective platform for building applications and solutions that incorporate 3D graphics and visualization, and that require real-time rendering at scale. It is particularly suitable for use in IoT scenarios where 3D graphics and visualization are important.

Developing for this service requires making use of the existing REST APIs. Those are:

  • Azure Mixed Reality Resource Management REST API
  • Remote Rendering REST API

There is an extensive Microsoft.Azure.RemoteRendering API library available for C#.

Spatial Anchors

Azure Spatial Anchors is a service that enables you to create and manage digital anchors in physical spaces. It can be used to build IoT applications and solutions that incorporate location-based functionality and support mixed reality scenarios. I think one of the best examples of this technology that many people are probably familiar with is the mobile game Pokemon Go. This massive multi-player platform allows gamers to track, capture, train, and battle fantasy creatures in a mixed-reality environment.

Its key features and capabilities include:

  1. Digital anchor creation: You can define the properties and relationships of the anchors in the digital model, and integrate data from external sources such as sensors and devices.
  2. Mixed reality integration: Azure Spatial Anchors can be integrated with mixed reality platforms and tools, such as HoloLens and Unity.
  3. Real-time anchor tracking: It supports real-time tracking of the digital anchors, allowing you to update the location and orientation of the anchors in the mixed reality application in real-time.
  4. Cloud-based anchor management: It provides a cloud-based platform for managing the digital anchors, which is useful for applications and solutions that need to support large numbers of users or devices, or handle large volumes of data.

Overall, Azure Spatial Anchors is a powerful platform for building mixed reality applications and solutions that incorporate location-based functionality. It is especially suitable for IoT scenarios where mixed reality and location-based functionality are important.

There are multiple Spatial Anchors SDKs:

  • SDK for Unity
  • SDK for iOS Objective-C
  • SDK for Android Java
  • SDK for Android NDK
  • SDK for HoloLens C++/WinRT
  • Azure CLI
  • Azure Powershell

There are multiple samples to work through to learn this resource. Again, this is another one of the family of resources that helps bring real world data to life in the digital world.

Time Series Insights

Azure Time Series Insights is a cloud-based platform that allows you to store, visualize, and analyze time series data in real-time. It is included in the Azure IoT resources because it can be used to build IoT applications and solutions that need to process, analyze, and visualize large volumes of time series data in real-time.

Some of its key features and capabilities include:

  1. Time series data storage: Azure Time Series Insights provides a scalable and highly available data store for storing time series data. It can handle large volumes of data and supports a variety of data types and formats.
  2. Real-time data visualization: Azure Time Series Insights offers a range of visualization tools and interfaces that allow you to view and analyze time series data in real-time. You can use the Azure Time Series Insights portal, Azure Grafana, or the Azure Time Series Insights REST API to visualize and explore the data.
  3. Query and analysis: Azure Time Series Insights provides a query language and a range of analytical functions that allow you to perform complex queries and analysis on the time series data. This can be useful for applications and solutions that need advanced analysis.
  4. Integration with other Azure services: Azure Time Series Insights can be integrated with other Azure services, such as Azure IoT Hub and Azure Stream Analytics, to build IoT applications and solutions that incorporate time series data and analysis.

Overall, Azure Time Series Insights is a powerful platform for building IoT applications and solutions that need to process, analyze, and visualize large volumes of time series data in real-time. It is particularly well-suited for scenarios where real-time data analysis and visualization are important.

Azure Time Series Insights and Azure Data Explorer are both cloud-based platforms designed to store, process, and analyze large volumes of data in real-time. However, there are key differences between the two.

Data types and formats: Azure Time Series Insights is designed for time series data, which is data collected and recorded over time at regular intervals. Azure Data Explorer is more general-purpose, and can handle structured and unstructured data.

Query language: Azure Time Series Insights uses Kusto Query Language (KQL) for time series data. Azure Data Explorer also uses KQL, but it is more flexible and can query a wider variety of data types and formats.

Visualization: Both platforms offer visualization tools and interfaces for viewing and exploring the data. Azure Time Series Insights is more specialized for time series data, and provides visualization options specifically designed for it.

Integration with other Azure services: Both platforms can integrate with Azure IoT Hub and Azure Stream Analytics, but the specific integration options and capabilities may vary.

Overall, Azure Time Series Insights is specialized for time series data, while Azure Data Explorer is more general-purpose.

Other Services

There are additional services that don’t fit into the IoT resources category, but are often used with Azure IoT Hub to fulfill the backend data processing needs of an IoT platform. These include:

  • Azure Functions
  • Azure Event Hubs
  • Azure Synapse
  • Azure Storage
  • Azure Databricks

Choosing the Right Azure IoT Hub SDK

Azure IoT Hub SDKs are available for multiple languages, platforms, protocols, and devices, and should be chosen based on the specific needs of the IoT solution. Best practices for using the SDKs include using the most recent version, following the recommended architecture, using the async programming model, and using secure communication protocols. Message routing, device twins, and device identities and keys should also be used to optimize the performance and security of the solution.

Factors to consider when choosing an Azure IoT Hub SDK

Consider several factors when selecting the right Azure IoT Hub SDK:

  1. Language support: Choose an SDK that supports the programming language you are using for your IoT solution. Azure IoT Hub SDKs are available for C, C#, Java, Node.js, and Python.
  2. Platform support: Consider the platform you are using for your IoT solution. Azure IoT Hub SDKs are available for Windows, Linux, and MacOS.
  3. Protocol support: Choose an SDK that supports the protocol you are using for communication between your IoT devices and the cloud. Azure IoT Hub supports MQTT, AMQP, and HTTP.
  4. Device support: Consider the type of device you are using and choose an SDK that supports the necessary features and capabilities. For example, if you need secure communication, make sure the SDK you choose supports secure communication protocols.
  5. Ecosystem integration: If you are building an IoT solution that integrates with other Azure services or third-party tools, choose an SDK with the necessary integration capabilities.
  6. Ease of use: Consider the learning curve and documentation associated with the SDK. Choose an SDK that is easy to use and has clear documentation to help you get started quickly.
  7. Development environment: Consider the development environment you are using, and choose an SDK that is compatible with your environment.
  8. Performance: Consider the performance needs of your IoT solution and choose an SDK that can meet those needs.
  9. Cost: Consider the cost of the SDK and whether it fits within your budget.

Best practices for using Azure IoT Hub SDKs in different scenarios

Make sure to use the most recent version of the Azure IoT Hub SDKs to take advantage of new features and improvements. Follow the recommended architecture to ensure that your solution is scalable, reliable, and secure. Use the async programming model to use non-blocking code and optimize performance. Secure communication protocols, such as TLS, should be used to protect the data transmitted between devices and the cloud. Device-to-cloud messages should be used for critical data that needs to be stored and analyzed. Cloud-to-device messages can be used to control devices or send commands. Message routing can be used to filter and route messages based on the content of the message or the device that sent it, helping to scale the IoT solution and process messages more efficiently. Device twins allow for managing the state of devices and synchronizing their state with the cloud. Finally, device identities and keys should be used securely and protected from unauthorized access.

Conclusion and Future Directions

The potential of Azure IoT Hub SDKs to drive business value

Azure IoT Hub SDKs offer several potentials to drive business value:

  1. Improve efficiency and productivity: Automate processes, gather real-time data, and enable remote monitoring and control with IoT solutions built using Azure IoT Hub.
  2. Increase customer satisfaction: Better understand and meet customer needs, leading to increased satisfaction and loyalty.
  3. Enhance decision making: Collect and analyze real-time data from IoT devices to make more informed decisions and improve operations.
  4. Improve asset management: Track and monitor the performance and maintenance of assets, leading to improved asset utilization and reduced downtime.
  5. Generate new revenue streams: Offer new products and services, create new business models, and open up new revenue streams with IoT solutions.
  6. Reduce costs: Optimize resource usage, improve maintenance schedules, and automate processes with IoT solutions.
  7. Increase competitiveness: Give businesses a competitive edge by providing them with a way to differentiate themselves and offer unique value to their customers.

Edge computing involves processing data closer to the source of the data, reducing latency, improving performance, and reducing the amount of data sent to the cloud. 5G networks are enabling faster and more reliable IoT connectivity, enabling new use cases and applications. Artificial intelligence and machine learning are being integrated into IoT solutions, making them more intelligent and autonomous, with the ability to learn and adapt. Blockchain technology is being used to improve security, traceability, and trust. The IoT is being applied in healthcare for remote monitoring, diagnostics, and treatment (IoMT). It is also being used in industrial settings, improving efficiency, maintenance, and safety (IIoT). Smart cities are being created with the IoT, enabling improved public services, transportation, and environmental sustainability. Augmented reality and virtual reality are being integrated into IoT applications, creating immersive and interactive experiences.

Closing

Azure IoT Hub Device SDKs are software development kits that enable developers to create applications that run on IoT devices and connect them to Azure IoT Hub. These SDKs provide a set of APIs and libraries that allow devices to perform basic and complex IoT device-to-cloud communications and commands, and support a wide range of programming languages and platforms. Common use cases include sending telemetry data, receiving commands, connecting devices using various protocols, authenticating devices, handling messaging, managing device twins, and receiving notifications.

Azure IoT Edge is a fully managed service that enables developers to deploy cloud intelligence directly onto IoT devices. It consists of edge modules, an IoT Edge runtime, and Azure IoT Hub. This allows developers to create and deploy intelligent edge solutions that bring the power of the cloud to the edge of the network.

This article has presented some of the major SDKs related to IoT and some of the related Azure IoT resources. It brings these resources together to show the array of options available to the Azure IoT developer. If a favorite was left out, please leave a comment. It could be a subject of a future post.

Posted on Leave a comment

Matter: a Unifying Standard for Home Devices or Hype?

In this short article I want to discuss the release of the recent standard, Matter, formally CHIP (Project Connected Home over IP). Will we have a consumer device communication standard that’s ideal for the smart home or are we looking at yet another standard that will further complicate IoT for the our smart appliances?

Matter was parented by the Connectivity Standards Alliance and release to the world this month. Version 1 is available now for review by manufacturers, developers, and anyone curious about this new means of device communications.

https://csa-iot.org/developer-resource/specifications-download-request/

The goal of this standard is to make interoperability among home devices easier. And because the standard has backing from Samsung, Google, Apple, and a large number of other organizations with interest in the home device market, there appears to be a fair chance the standard will stick.

The promise seems to be less hassle for the user. When you purchase a product that adheres to the Matter standard, you should be able to easily connect and integrate with other devices in your home using that standard.

But what about security? Even at this moment, I can connect to my neighbor’s TV from my iPad if I wanted to. How do we make sure that these devices are safe, even for those who aren’t the most technically skilled?

According to their security white paper, Matter follows five security tenets:

  • Comprehensive – they use a layered approach
  • Strong – they use well-tested, strong cryptography
  • Easy – security should improve ease of use, or decrease it
  • Resilient – protect, detect, recover
  • Agile – able to respond quickly to threats

How easily will this be adopted by the developers? I did take a look at the source code and libraries. It’s written in C++, so it should be fast. And there appear to be libraries for most of your common development boards, chipsets, and MCUs. I think that’s good sign. You can see the repo here:

https://github.com/project-chip/connectedhomeip

So is it a viable standard or is it hype?

Matter was a long time in the making. And it’s creation required manufacturing rivals like Google, Apple, and Samsung to sit across from each other at a table and agree on one direction to take device communication. The standard was just released this month and the official launch is on November 3rd. There are already a large group of early adopters prepared to launch products. Some of your appliances under the Christmas Tree this year might be Matter compatible.

I think it’s safe to say that Matter isn’t just hype. It looks to be a great way for devices to communicate easily on a home network using common IP methods and options like WiFi and a new protocol called Thread. Maybe this time next year we’ll see more IoT innovation in our homes because of better device interoperability.

Posted on Leave a comment

Personal Post on My Continuing Journey with IoT Edge Computing

shawn deggans personal blog post

I made the biggest career change of my life recently.

I left the consulting firm I had been employed with for the past four years. It wasn’t an easy decision. I gave up a technical leadership role, I left a lot of people who I loved working with, and I gave up the security of a regular paycheck.

What was behind my decision?

Focus.

Focus was my primary reason for leaving. Two years ago I began a journey to learn and apply everything I would need to know to be a competent IoT Edge Architect. I began that journey with the hopes that my career would be heavily focused on helping organizations solve interesting problems using modern data analytics, IoT systems, and containerized machine learning on the edge.

That never really happened. I had the occasional opportunity to work with machine learning, Kubernetes, and some advanced analytics, but the bulk of interesting data work was done by other people while I focused on platform development.

I didn’t allow those IoT skills to go static though, because I did the occasional side work with partners focused on IoT, but my day job always came first. It reached the point that the day job wouldn’t allow time for anything other than the day job. I didn’t want those IoT skills to go stale, so I had to make the difficult decision. Do I stay where I am and try to be happy or do I pursue the career working with the technology I know actually moves the needle for organizations?

So here I am, completely independent. Ready to focus.

I got pretty good with infrastructure deployment and DevOps, so that’s the majority of the work the firm put me on. And they put me on a lot of it. Systems architecture and design became my everything for a while. Let me be clear that there’s absolutely nothing wrong with systems design work. It can be incredibly rewarding. It’s actually a big part of IoT Edge development. It just became clear to me that I was never going to have the opportunity to help build anything interesting on the infrastructure I was creating.

During my time with the firm, I went from a senior application developer to a cloud systems architect. It took me four years to make it happen, but it was definitely a necessary milestone for the next stage of my journey.

What is the next stage of my journey?

I’m returning my focus to IoT Edge computing.

What I want to do for my career is implement edge and IoT systems from multiple types of systems to multiple cloud and server solutions using modern communication systems, analytics, and security. I mean, for something that’s supposed to be a focus, that’s pretty broad. However, it all fits together nicely for certain, specialized use cases.

I have a lot of experience and a few certifications in Azure, so I have no plans to walk away from Azure any time soon, but I’ve had the opportunity to work with a few other products like InfluxDB, Milesight, Chirpstack, Eclipse Mosquitto, and I don’t want to limit myself to one cloud or one set of solutions. Much of my focus moving forward will be more on the IoT Edge System Design. The theory, the best practices, the understanding of why certain technologies are used over other technologies.

Basically, in order to improve my IoT Edge expertise, I need to say no to a lot of other types of work. Am I capable of helping an organization migrate all their SQL data systems from on-premises to the cloud? Yes, it’s completely within my wheelhouse. Could I build a distributed e-commerce solution using .Net applications in Docker containers for high availability using the best security Azure has to offer? Yes, also within my skillset. Will I take on any of that work? No. I won’t. And that’s the point I’ve reached in my career. I’m going to be very selective about the type of work I take on, and the type of clients who I work with.

That’s my goal. Focus. Be one of the best.

What can you expect from this blog?

It won’t change too much, but I will create more content. I do like doing technical deep dives, so you will see more of these. I also like to explore use cases. You’ll see more of that, especially in the Controlled Environment Agriculture industry. I believe this is an area that will need more help as our environment undergoes more changes in the coming years. If we want food in the future, we will need to know how to control our environments in a way that is economical and sustainable.

I will also write more about IoT architectures for multiple clouds and scenarios. sensors, endpoints, and power management. I want to look at how Claude Shannon’s Information Theory shapes the way we communicate between the cloud and devices. I will probably write far more about networking than you want to read, but it’s an area that I used to hate that I’ve now grown unreasonably in love with. Obviously, lots of discussion around Edge Computing, protocols, Fog computing, Augmented Reality, Machine Learning, MLOPs, DevOps, EdgeOps, and of course security.

That’s the technical side, but I also want to start working more with the community. DFW, Texas has quite the community of IoT organizations and engineers. I hope to connect with these individuals and organizations and capture some of ways I can help them, or they help me and record those outcomes here.

What about money?

Ah, yes. I do actually have bills to pay. So I will need to make money. Luckily, I’m in the financial position that I don’t necessarily need to earn a fulltime income immediately. I’m also fortunate enough to have work from one of my business partners that fits directly within my goals. We’re building an InfluxDB for some time series data and using Pandas to build some forecasting. I’ve also had my own LLC for a few years now, so the business side of things won’t be a hurdle.

But I do have additional plans. Next month I’m presenting a few ways that we can partner together, if you are interesting in working on an IoT Edge project. I’m opening my calendar to a small group of people for bookings through my company called, “Green Nanny LLC.” That’s a name you’ll see me mention more in the future as I build it out to its full intention.

Here are just a few of the services I’ll offer:

  • Assessments – are you ready for IoT Edge? Do you know what it is and how it applies to modern, distributed solutions? What does it look like, operationally? This helps you make better decisions and pick a direction for next steps.
  • Architecture design sessions – let’s think through the art of the possible using machine learning, IoT, and modern data analytics. What does your future system need to look like to support edge workloads?
  • Briefings – if we were to implement a project, what would it take? Do you need a proof-of-value to start or are you ready for a well-architected IoT solution?
  • Implementations- how can I help your team implement an IoT Edge solution?
  • POV – let’s see if we can create a proof of value in a very short period of time?
  • Team training – how can I help your team learn how to implement IoT Edge?
  • Well-architected review and recommendations- can we improve your existing solution? Do you need help with reliability, cost optimization, security, operational excellence, or performance?
  • Managed Service – what are some options for managing your IoT products using a managed services provider? I don’t provide this service myself, but I still have many connections who can help make this a reality.
  • Retainer – Do you just need someone with a lot of IoT Edge knowledge to bounce questions off of? Not sure where you want to start on your own IoT Edge journey, but would like a guide?

I’m excited for the future

I think and feel that I made the right decision for this move at the right time. My skills as an Azure Architect have put me in an excellent position to transition into something more specialized. The consulting work I did with the firm clarified the type of work I like to do, and the type of work that I’m good at. I see a lot of promise in my area of focus and a lot of financial opportunity for myself, my partners, and the clients who I will serve.

Posted on Leave a comment

The Smart Factory for Brewers isn’t Just for the Big Brewers; is Your Independent Brewery Ready for IoT, AI, and the Cloud?

Wouldn’t it be great if every beer bottle that left your brewery met with your exacting quality standards, if overflowing and excessive foaming were yesterday’s problem, and not a persistent, wasteful expense?

What if you could be consistently proactive in your quality control process, and not reactive to cases of returned beer and disappointed customers?

Independent breweries like Sugar Creek Brewing faced just such a problem, and according to this Forbes article, the problem cost the brewery $30,000 a month.

Independent, hand-crafted breweries are discovering what manufacturers have understood for decades. You can measure product quality with IoT. But many breweries, like Sugar Creek Brewing, are using AI to predict quality issues before they happen allowing brewers to proactively manage the quality of their beer.

The Smart Factory for the Independent Brewery

The smart factory for breweries is here. Connecting your brewery with IoT devices capable of streaming real-time data to the cloud, analyzing that data with AI, and creating a responsive feedback loop that your employees can use to consistently improve the brewing process is no longer a tool meant only for the larger brewers with immense IT teams and budgets.

To help pinpoint the specific causes of overflow and excessive foaming during the brewing and bottling processes, you can connect your equipment with embedded flow meters and sensors that allow you to collect a high volume of accurate data on pressure, temperature, pH balance, carbonation, fill time and more.

By collecting all this data and applying the correct analytics, you can discover insights about your operations, improve efficiency, stop equipment bottlenecks, and help your employees accomplish their daily tasks.

Working around high-pressure tanks presents big risks to employees working on the production line. With the right pressure sensors on every kettle, still, brewing pump, and with object detection in place, the factory floor can become a much safer place to work, as production managers can track performance issues that could lead to serious injuries.

The fermentation process is the heart of the brewery factory. What if you could get constant feedback on this process without opening that tank?

Breweries See a Return on their Investment with AI and IoT

Not only does the Smart Factory for Breweries improve efficiency, beer quality, and employee safety, but it also helps improve your brewery’s financials.

  • Save on returns from poor quality products
  • Reduce waste of materials for bad batches
  • Fully use capital equipment
  • Protect the health and safety of employees and customers
  • Reduce energy use
  • Monitor and track batches effectively for compliance and regulations
  • Save on parts and repairs using AI predictive maintenance
  • Control inventory with RFID tracking

The cloud has allowed the cost of analytics systems to drop significantly, and many IoT platforms can right-size their solutions to fit with your consumption, giving you the option to ease into your IoT and AI journey affordably.

Connecting KPIs as a Measure of Success

As a brewer, you’ll want goals and specific metrics tied to your Smart Factory for Breweries. Some of these include the following depending on your solution approach:

  • Equipment downtime for repairs
  • Predictive cleaning schedule vs set schedule
  • Returns from retailers because of quality
  • Bbl brewed per hour
  • Bbl packaged per hour
  • Bbl lost per hour
  • Bbl to energy costs

Your Business Processes will Need to Adapt

There are daily processes undertaken in the brewery that add to waste and risk contamination. The typical small brewery will draw liquid from the tanks daily to check for quality, consistency, and the state of the fermentation process. This is the process of monitoring specific gravity. It’s not a great process when managed manually, because only checking once or twice a day isn’t likely to catch a problem quickly enough, and with each test the product is exposed to possible contamination.

To reduce the risk of contamination and increase regular monitoring, it makes sense to add a sensor to the tank to collect data. The data collected from the tank can then inform operations.

But how is this continuous monitoring done on large tanks that are usually made of copper or industrial steel? This is where it helps to understand the problem and find the right IoT device for the job. In this case, low energy Bluetooth devices floated in the liquid can communicate with gateways positioned nearby. This allows IoT to completely replace a manual process, as well as do a better job of monitoring for regular consistency.

This is why it’s important to work directly with a partner who can help match the right product with the situation. A great partner will learn your business processes and won’t be afraid to point out where your business process will need to adapt to fit with the innovation the technology brings.

A Use Case: Automate the Manual Method of Measuring Specific Gravity

Brewers are well aware of how this process works, but for this use case I’ll summarize it:

Specific gravity will indicate the stage of fermentation. Brewers use this measurement to determine the state of fermentation—is it on track, done, or perhaps stuck. Yeast can stop consuming sugar too early, and when this happens the brewer needs to take steps to save the batch. This is one of the reasons continuous monitoring is required for the modern brewery. The sooner you’re aware of a stalled batch, the sooner you can undo the damage.

This is typically measured using the manual method described above. The actual measurement is looking at the liquid’s density in comparison to water. As beer ferments and coverts sugars to alcohol and gas, the specific gravity falls and the liquid gets less dense. Eventually, there are few sugars left and the fermentation process slowly stops.

It’s clear to see why putting a machine in charge of monitoring this process consistently helps improve this task.

But what does this look like, technically? Are there tools and systems in place today to make this easy to install and monitor without risking batches of beer or installing expensive equipment?

Tilt Pro, Bluetooth, and IoT Central

If we focus on one particular use case, like measuring specific gravity, there are a number of ways to accomplish this, but the following architecture is one that I recommend. This architecture is built for a small brewery with just a few fermentation tanks. It uses off-the-shelf devices and requires minimum programming to get the solution up-and-running. But it also has room to grow into a robust platform for managing more than just fermentation monitoring.

FERMENTATION TANKS

The assumption is that you’re using industry standard fermentation tanks. These are, without a doubt, a challenge for electronics equipment. Most are made of steel or copper, which means that they basically act like a Faraday Shield capable of blocking or dampening signals.

Some IoT devices will not work in this situation. So either you need a wired solution or something clever like the Tilt Hydrometer. When I first discovered this device I thought that perhaps it was a toy for homebrewers. Surely, nothing as low in price as this device could have professional applications, right? Well, after reviewing the device and seeing it’s capabilities on paper, I’m willing to include it in this architecture.

Especially, backed up by a custom device to work with the iBeacon signal generated from the Tilt. For this architecture, I’m recommending the Tilt Pro. The standard Tilt device might be adequate, but I think it’s worth the extra money for the added battery life and sensor capabilities.

The Tilt device goes inside the tank, but it’s enclosed in a protective shell. Cleaning and care instructions are available on their website. Here’s the marketing breakdown on the device:

At 3x the volume and weight of our original Tilt hydrometer, the Tilt Pro’s larger size allows us to more than double the battery life with preinstalled Energizer® AA lithium batteries that will keep it powered for 3 to 5 years depending on use. So much time you may forget your Tilt actually runs on a battery! The extra size and weight comes with an extra bonus: improved specific gravity stability at high krausen so you will see a steadier read-out on your iPhone, Android, or Raspberry Pi. In addition, we have boosted range with a high-gain antenna that in testing increased range by 20% vs. our original Tilt. Now you can see your Tilt through thicker heads of foam and heavier stainless steel walls. To top it off we’ve included the extra decimal of precision available from the sensors and to the read-out so there are now decimal degrees Fahrenheit as well as higher resolution Celsius. Specific gravity now reads out to the 10,000th place (for example 1.0000). You can now see fermentation activity dropping less than a brewer’s point per day. In all we’ve made several adjustments we believe the craft beer professional (and serious home brewer) is sure to appreciate.

The Tilt’s cloud backend is basically writing data to Google Sheets. We definitely don’t want to write our data to Google Sheets. No offense to Google Sheets. It’s a great app for many purposes, but we want something a bit more robust. I also do not want a mobile app. I want a device dedicated to capturing the Bluetooth signal, converting the raw message from that signal to MQTT, and delivering that to a server on the Brewery’s internal network.

DATA FLOW FROM TANKS TO EDGE GATEWAY

The basic flow of data from tank to IoT gateway looks like the following:

The Tilt is a one-way leaf device and it’s tightly coupled to a nearby Raspberry Pi Zero W. By nearby, I mean as close to the tank as possible, other than inside of it.

The Pi gives us a lot of development options. We could, if we wanted to, connect the Pi directly to Azure IoT Central. This would make it a gateway device. It would still need a WiFi router or hub to connect to, but it could manage two way communication with IoT Central.

For this architecture, though, I want to couple a Pi with each Tilt. Considering that the cost of each device is minimal and the power you get when you add a more robust gateway, like the Ectron Edge Computer ECT-ECI, this allows us to remain technically small and simple, but with the option of applying more sophisticated Edge Patterns.

For instance, there might come a future date when I want to I want to deploy machine learning modules to the Pi. These modules could be specific to each tank’s beer, allowing brewers the ability to monitor for different types of beer.

THE ARCHITECTURE

The following is our more robust design.

I want to continue with the idea that this is just a proof-of-concept set with one use case. However, I’ve expanded out to manage three different tanks. Each tank as been coupled with its own Tilt device, Raspberry Pi Zero W, and all three of these connect to the Ectron Edge Computer.

Where we start to flesh out the solution, is when we collect the data in the cloud. Here we’re using Azure’s IoT Central, but we could just as easily use any other cloud IoT platform. I like IoT Central because it’s quick to get an app up-and-running, it makes device management simple, and includes all the analytics you need to prove out an IoT POC.

It’s also scalable, so building out to more devices and more use cases is easy. IoT Central is meant for smaller to mid-sized IoT projects, but it can still support multiple organizations in production scenarios.

When you start to work with more than one million devices, though, IoT Hub, AWS IoT SiteWise, or Google’s IoT Core are better choices. Though I designed this with Azure in mind, the Gateway is flexible enough to work with any cloud backend IoT service.

A couple of future use cases we could explore once this platform is built:

  • Use Machine Learning to predict fermentation stages for specific beers
  • Use time series analysis to detect anomalies in the brewing process
  • Collect data specific to certain recipes, build guidelines and intelligent monitoring around these recipes, and alert Brew Masters to tanks that drift outside the confines of the established guidelines

Who do I need to put this solution into place?

The team to build this out could be relatively small. One person with the right skills could build this entire solution, but what skills will they need?

  1. The Tilt devices are relatively complete. As an off-the-shelf solution they provide a lot of flexibility. To work with this device, you’ll need to understand how to collect Bluetooth Beacon data. Lucky for us, Tilt includes a link to work with this data from their website’s FAQ. https://kvurd.com/blog/tilt-hydrometer-ibeacon-data-format/
  2. Creating the coupled Pi Zero will pose a slightly bigger challenge. This isn’t an out-of-the-box solution, but it isn’t undiscovered country either. Basically, we want to run Containerd and the IoT Edge Modules on the device. This will allow us to deploy to the Pi as though it were an Edge Device. We could also use the IoT Central SDKs to create a basic device and send data. We have a few choices here but ideally, you want to capture the BLE message, format it to something that best fits the use case, and then wrap that in an MQTT message to send to IoT Central.
  3. The Edge Gateway is probably one of the easier pieces to implement. This article covers the process, so I won’t dive into it here: https://docs.microsoft.com/en-us/azure/iot-edge/how-to-connect-downstream-iot-edge-device?view=iotedge-2020-11&tabs=azure-portal
  4. Setting up the Edge Gateway and devices in IoT Central, is also trivial, but that might be a different person completing the set up than the device developer.

Basically, if you have someone with experience developing IoT Edge modules, lite Python programming skills, and IoT Central administration basics, you could have a solution up-and-running quickly.

Is this Secure?

If you keep the signals within the brewery on their own dedicated network and authenticate the devices through IoT Central, it should be secure. The real trick here is to make sure you provide a separate network on your brewery floor from the rest of the company’s network. For instance, many breweries are also open to the public for dining and tours. You don’t want the public to even be able to see the brewery floor network, much less access it from their devices.

In this scenario, the endpoints for IoT Central are the only exposed URLs. You can protect these with device authentication. Logging into IoT Central as an administrator would be protected by Azure Active Directory using MFA.

What about my data? Is it backed up?

IoT Central only stores about 30 days worth of data, but there are means of integrating storage solutions with your IoT Central App. This isn’t reflected in this architecture, but at a minimum I would recommend adding an Azure Storage Account to retain messages. You’ll likely want this data for future data science and trend analysis.

What if I have more than one brewery?

This solution isn’t designed for extreme robustness or resilience. I definitely put this solution in the category of proof-of-concept or minimal viable product. If you set this up, and you like your initial tests, and you feel like this is something that could expand to multiple physical locations, IoT Central can definitely handle this up to 1 million devices. If your device requirements look like they will spread beyond that number, it’s time to consider Azure’s IoT Hub solution with a more complete Azure Analytics backend. Synapse or Databricks with Azure Time Series Insights make great additions to this type of architecture.

How do I manage this environment

As long as this is kept small, it’s probably ideal for a single developer or administrator. IoT Central has a few built in roles that the administrator or App owner can assign to users so they have access to dashboards. At a minimal, I would consider these roles in IoT Central:

  • Application Administrator can manage and control every part of the application – give this role to someone in your IT operations department
  • App builder has many of the same abilities as the Admin, with the exception that they can’t make administration changes or connect to data exports
  • The Operator role is ideal for someone who needs to monitor device health and status. This is for anyone working the brewery floor

Those are basic roles. If you begin to build your solution out to multiple locations, these can be defined as Organizations. If I own a brewery in three different cities in my state, I might have my Fort Worth brewery, my Dallas brewery, and my Austin brewery. I would separate those by Organization and assign the above roles to users in those areas.

What can I do with this platform, once it’s up-and-running?

IoT Central comes with many tools needed to run operational IoT.

  • Robust Dashboards that can be customized for many different views
  • Device life-cycle management and Gateway management
  • Rules triggered based on telemetry with built in messaging to email, webhook, Azure Monitor Action Groups, Microsoft Power Automate, and Microsoft Azure Logic Apps
  • Time-series Analytics allows you to create and save queries
  • Run jobs on device groups that can send commands to devices or change device properties
  • Build and store device templates
  • Export to multiple data sources
  • Complete administration of the app, the users, and pricing

In addition to the IoT Central benefits, you can build upon the IoT Edge devices by integrating device specific logic or machine learning models.

If I have an IT team, will they need a lot of training?

Perhaps, if they aren’t familiar with IoT. However, Azure does make some of this fairly easy. It helps to work with a partner who understands how to make cloud solutions operational. Knowing and understanding the burdens and responsibilities of a lights-on operations team will help your partner understand what things the team needs to monitor for and integrate into your team’s existing playbooks and operations procedures.

I’m interested to see how IoT can help my brewery

If you aren’t already using IoT in your brewery, it’s important to understand that there is a learning curve. As I’ve outlined here, it takes some time to understand how the technology can help you and how you might need to adapt to the technology. If you have the right partner, this can be a smooth transition. There are definitely some key stages I think a partner should walk you through before you make a large financial commitment.

  1. Be careful with any solution that appears to be a one-size fits all. Your brewery is unique. Your product is unique. You didn’t become an independent, craft brewer because you wanted to mimic a certain company with the initials of AB. So AB’s amazing, multi-million dollar IT solution probably isn’t right for you.
  2. This isn’t a quick, one-and-done project. IoT is a journey best taken in measured steps. The right partner is going to understand that process and they will help guide you along the path.
  3. The right partner takes a wholistic view of you, your brewery, and cares about your bigger picture goals. Selling gadgets is great, if all you do is sell gadgets, but a solutions partner wants to make sure you have the right gadget for your needs.

Solution Visioning

Expect a couple of workshops from your solution partner. Believe it or not, these aren’t just a way to make more money off of you. These are a necessary part of the process. A partner needs to learn about you, your business, your aspirations and your challenges. These envisioning workshops are a way to achieve that.

Architectural Understanding

A good partner will want to understand your network topology, but also your enterprise architecture. Not just the technical systems, but your policies, procedures, your team structure, and even your company culture.

POCs and Pilots

Smaller, measured steps into a bigger picture solution is a great way to learn, without breaking the bank. The days of huge, multi-year projects only to deliver a technical nightmare that doesn’t meet your needs is gone. Be ready to work with a partner willing to take small steps toward bigger goals.

  • Limit your use case to one single point of value
  • Limit your scope to one particular area of the brewery
  • Time-box your efforts. Don’t make the mistake of trying to enforce an artificial deadline, but don’t get mired in complexity.
  • A POC won’t be production ready, but it will be testable with real-world scenarios
  • Take this opportunity to learn and try to avoid assumptions
  • It might require multiple POCs to arrive at a worthwhile pilot
  • It will require your time, the time of your staff, and your feedback—you can’t hand off your standard operating procedures and expect a bespoke solution to your particular needs

How do we make this production ready?

When you’re prepared to take this solution to production, there are a few factors to consider.

  1. How do we reach zero-trust security with this platform? Are our users authenticating using MFA. Does each user have the least privileges possible? Are my devices hardened against tampering? Are my Edge devices loaded with security modules?
  2. Do I have system oversight? Is there the appropriate level of logging and log monitoring in place? Are there alert groups established in Azure. Are these alert groups receiving alerts from IoT Central, devices, and any other backend analytics systems?
  3. Is data backed up securely? Is access to this data limited to integrated systems? Is access to the data monitored?

There are other considerations like building out staging layers for developers and testers. A more complete security monitoring tool like Microsoft Defender for Cloud should be a consideration. Hiring penetration testers to test your security is also a good idea.

Teaching your team how the system works

Hopefully your team has been involved from the beginning. A good IoT integration partner will talk to the brewery floor crew during development and system installation, get their feedback for alerts and dashboards, and familiarize everyone with the systems as it’s built.

Good formal training for the brewer floor will be something a partner can provide. Delivering this training in documentation, video, and one-on-one sessions is the typical method for handing off a production system. As your system grows and matures, you’ll eventually want staff trainers who have made your technical solutions part of your floor’s standard operating procedures.

What if I need continued help after the solution is built?

Let your partner supplement your time with ongoing support and monitoring. Many IoT developers and integrators either have a managed service team or they outsource that job to a trusted partner. If you don’t have the IT staff to manage and monitor your solution, your IoT partner should be able to provide one for you at an affordable rate.

Who do I include in partner meetings?

Independent brewers tend to keep the company lean. Titles like CEO, CTO, and CFO might not exist. That’s not a problem. The people who need to be at the table are decision makers, financiers, brewery operations experts, and trusted advisers.

Are you available to help us?

Yes, as a certified Azure IoT specialist and AI Engineer with twenty years of IT experience, I’m in the ideal place to help with this exact type of solution. I’m a strong advocate of cloud transformation. I’ve helped large and small organizations transform their operations using Azure and Big Data analytics platforms. I’d love the opportunity to work with a brewery interested in exploring how IoT could improve their operations and save them thousands of dollars a month.

What are the next steps?

Are you happy with your current brewery floor operations? Now that you know there are better ways to brew beer, can you continue to operate the same way moving forward? Inertia is difficult to break, but one thing that helps is a clear decision. Is a Smart Factory for Breweries something you’re ready to take on? Or can you continue on your present path?

When it comes to these type of decisions, it’s usually best to start small. This is one of the reasons I’m an advocate of the POC. With a small equipment investment, an Azure subscription that only charges based on consumption, and a hands-on consultant who can take you through every step of the process, it’s easier now than ever before to test your ideas without breaking the bank.

The cloud, IoT, and AI are tools that brewers use to improve operations, innovate, and save money. If you’re interested in seeing if this is the right path for your brewery, I’m here to help.

Posted on Leave a comment

I Read and Summarized the 3rd Edition of IoT Signals So You Don’t Have to

A report built based on survey data taken by the company named, ‘hypothesis’. This is a combined effort between Microsoft and Hypothesis to capture the most current state of IoT from the view of business leaders in certain sectors; manufacturing, energy, mobility, and smart places.

The survey was multi-national and the report includes data captured from in-depth interviews.

Things to know about IoT in 2021

The following are high-level conclusions drawn from the interviews and survey data:

  • IoT continues to drive organizations toward a more productive future
  • COVID-19 has accelerated IoT strategies and fueled business growth
  • AI, Edge Computing, and Digital Twins are essential to advance IoT strategies
  • Although IoT projects are maturing, technological complexity persists
  • Organizations are keeping a close eye on data security

Who they talked to

  • Business decision makers, developers, and IT decision makers who work at enterprise-size companies with greater than 1k employees
    • 71% were familiar with IoT
    • 95% of those familiar, have influence and decision making power on IoT strategies
      • 10% of those familiar were not in adoption of IoT
      • 90% of those familiar were in adoption of IoT

Overall Research Learnings

Big Picture

This year, IoT continues to be widely adopted. 90% of organizations surveyed are IoT adopters. IoT projects can be categorized into four stages:

  • Learn
  • Trial / Proof of Concept
  • Purchase
  • Use

Of the 90%, at least 82% have a project that reached the “use” stage.

The state of most projects overall:

  • 29% in Learn
  • 25% in Trial / POC
  • 22% in Purchase
  • 25% in Use

IoT adoption and value globally (Australia, Italy, and the US lead as primary adopters)

  • 90% of the surveyed leaders in countries fitting criteria are adopters
  • 25% have projects in use
  • Average time to reach “use” is 12 months
  • 66% plan to use IoT more in the next 2 years

IoT Adoption and Value by Industry

  • Manufacturing
    • 91% of the surveyed leaders in countries fitting criteria are adopters
    • 26% have projects in use
    • Average time to reach “use” is 13 months
    • 68% plan to use IoT more in the next 2 years
  • Energy
    • 85% of the surveyed leaders in countries fitting criteria are adopters
    • 22% have projects in use
    • Average time to reach “use” is 15 months
    • 61% plan to use IoT more in the next 2 years
  • Mobility
    • 91% of the surveyed leaders in countries fitting criteria are adopters
    • 23% have projects in use
    • Average time to reach “use” is 14 months
    • 61% plan to use IoT more in the next 2 years
  • Smart Places
    • 94% of the surveyed leaders in countries fitting criteria are adopters
    • 24% have projects in use
    • Average time to reach “use” is 13 months
    • 69% plan to use IoT more in the next 2 years

Why Adopt IoT

Overall Top 5 reasons:

  • Quality Assurance : 43%
  • Cloud Security: 42%
  • Device and Asset Security: 40%
  • Operations Optimization: 40%
  • Employee Productivity: 35%

The report includes evidence that those companies who employ IoT to improve products and service see a higher increase in overall ROI.

Manufacturing Top 5:

  • Quality and compliance
  • Industrial automation
  • Production flow monitoring
  • Production planning and scheduling
  • Supply chain and logistics

Energy (Power and Utilities) Top 5:

  • Smart grid automation
  • Grid asset maintenance
  • Remote infrastructure maintenance
  • Smart metering
  • Workplace safety

Energy (Oil and Gas)

  • Workplace safety
  • Employee safety
  • Remote infrastructure maintenance
  • Emissions monitoring and reduction
  • Asset and predictive maintenance

Mobility

  • Inventory tracking and warehousing
  • Manufacturing operation efficiency
  • Surveillance and safety
  • Remote commands
  • Fleet management

Smart places

  • Productivity enablement and workplace analysis
  • Building safety
  • Predictive maintenance
  • Regulations and compliance management
  • Space management and optimization

Benefits of IoT

Top 5 benefits organizations are reaping from IoT

  • Increases in efficiency of operations
  • Improved safety conditions
  • Allows employees to be more productive
  • Allows for better optimization of tools and equipment
  • Reduces chance for human error

Common measures of success in IoT

  • Quality
  • Security
  • Production Efficiency
  • Reliability
  • Cost efficiency

Less common measures of success

  • More informed decision making
  • Direct impact on increased revenue
  • Sustainability
  • % of project deployed using IoT

Challenges of IoT

Top 5

  • Still implementing our current solution
  • Security risk isn’t worth it
  • Want to work out existing and future challenges before adding or using IoT more
  • Too complex to implement because of technology demands
  • Too complex to implement because of business transformation needed

Top 5 reasons POCs fail

  • High cost of scaling
  • Lack of necessary technology
  • Pilots demonstrate unclear business value or ROI
  • Too many platforms to test
  • Pilot takes too long to deploy

Top 5 security concerns

  • Ensuring data privacy
  • Ensuring network-level security
  • Security endpoints for each IoT device
  • Tracking and managing each IoT device
  • Making sure all existing software is updated

The report includes a section on best practices, and notes that despite security being a big concern, very few are implementing these best practices:

Top 5 best practices

  • Assume breaches at every level of IoT project
  • Analyze dataflows for anomalies and breaches
  • Define trust boundaries between components
  • Implement least privileged access
  • Monitoring 3rd party dependencies for common vulnerabilities

IoT Implementation Strategy

Most of the companies surveyed prefer to work with outsourced resources to implement their IoT strategy. They do prefer bespoke solutions.

Those who outsource see these positive benefits:

  • Increases efficiency of operations
  • Improves safety conditions
  • Reduces changes for human error

Those who do not outsource tend to hit these challenges:

  • Too complex to implement because of business transformation needed
  • Too long to implement
  • No buy-in from senior leadership

Sustainability

Companies with more near-term zero carbon footprint goals are more motivated to implement IoT to help than those who have a longer range target.

Impact of COVID-19

When asked if C-19 was an influence in investing:

  • 44% more investment
  • 41% stay the same
  • 7% less
  • 4% too early to tell

Emerging Technologies

Those who are adopting IoT are more likely to adopt other innovative technology associated with IoT:

  • Digital Twins
  • Edge Computing
  • AI at the Edge

This is collectively known as AI Edge

AI Implementation

84% Have a strategy:

  • 31% are implementing
  • 26% developed, but not implemented
  • 26% developing

16% do not have a strategy

  • 11% want to develop
  • 5% have no plans

79% of respondents claim that AI is a core or secondary component of their overall IoT strategy

Top 5 reasons for AI in IoT Adoption:

  • Predictive maintenance
  • Prescriptive maintenance
  • User experience
  • Visual image recognition and interpretation
  • Natural language recognition and processing

Top 5 Barriers to using AI within IoT

  • Too complex to scale
  • Lack of infrastructure
  • Lack of technical knowledge
  • Implementing AI would be too complex
  • Lack of trained personnel

AI Adoption and Value by Industry

Total:

  • 84% – have an AI strategy
  • 31% – Implementing
  • 26% – developed
  • 26% – developing
  • 79% – use AI in IoT solution

Manufacturing:

  • 84% – have an AI strategy
  • 31% – Implementing
  • 23% – developed
  • 30% – developing
  • 83% – use AI in IoT solution

Energy

  • 90% – have an AI strategy
  • 26% – Implementing
  • 28% – developed
  • 36% – developing
  • 89% – use AI in IoT solution

Mobility

  • 81% – have an AI strategy
  • 36% – Implementing
  • 25% – developed
  • 20% – developing
  • 85% – use AI in IoT solution

Smart Places

  • 88% – have an AI strategy
  • 39% – Implementing
  • 28% – developed
  • 21% – developing
  • 75% – use AI in IoT solution

Edge Computing

Edge Computing Implementation Progress

79% have a strategy:

  • 29% implementing
  • 26% developed but not implemented
  • 24% developing

21% do not have a strategy:

  • 15% want to develop
  • 6% have not plans

81% Edge Computing as a core or secondary component:

  • 42% Core
  • 39% Secondary
  • 18% Considering, not yet adopted
  • 1% not considering

Top 5 Reasons to adopt Edge Computing

  • Cloud security
  • Device and asset security
  • Quality assurance
  • Securing the physical environment
  • Operations Optimization

Top 5 barriers to adoption

  • Lack of architectural guidance
  • Lack of trained personnel
  • Lack of infrastructure
  • Difficulty managing security
  • Lack of clarity on edge hardware choices

Edge Computing Adoption and Value by Industry

Total:

  • 79% – Have Edge Computing strategy
  • 29% – implementing
  • 26% – developed
  • 24% – developing
  • 81% – Use Edge Computing in IoT Solutions

Manufacturing:

  • 83% – Have Edge Computing strategy
  • 37% – implementing
  • 28% – developed
  • 18% – developing
  • 77% – Use Edge Computing in IoT Solutions

Energy:

  • 85% – Have Edge Computing strategy
  • 38% – implementing
  • 25% – developed
  • 23% – developing
  • 85% – Use Edge Computing in IoT Solutions

Mobility:

  • 85% – Have Edge Computing strategy
  • 18% – implementing
  • 30% – developed
  • 37% – developing
  • 88% – Use Edge Computing in IoT Solutions

Smart Places:

  • 85% – Have Edge Computing strategy
  • 29% – implementing
  • 26% – developed
  • 30% – developing
  • 83% – Use Edge Computing in IoT Solutions

Digital Twins

77% have a strategy:

  • 24% implementing
  • 29% developed, but not implemented
  • 24% developing

23% do not have a strategy:

  • 14% want to develop
  • 9% have no plans

81% Use and Impact of DT on IoT Solutions

  • 41% feature as core component
  • 40% feature as secondary component
  • 18% considering, but not yet adopted
  • 1% not considering

Top 5 benefits of using DT within IoT:

  • Improve overall quality
  • Increase revenue
  • Reduce operations costs
  • Enhance warranty cost and services
  • Reduce time to market for a new product

Top 5 barriers:

  • Challenges managing the value of data collected
  • Complexity of systems needed to handle digital twins
  • Integration challenges
  • Lack of trained personnel
  • Challenges modeling the environment

Digital Twins Adoption and Value by Industry

Total:

  • 77% – have a DT strategy
  • 24% – implementing
  • 29% – developed
  • 24% – developing
  • 81% – use DT in IoT solution

Manufacturing:

  • 79% – have a DT strategy
  • 31% – implementing
  • 25% – developed
  • 23% – developing
  • 86% – use DT in IoT solution

Energy:

  • 79% – have a DT strategy
  • 26% – implementing
  • 29% – developed
  • 24% – developing
  • 82% – use DT in IoT solution

Mobility:

  • 76% – have a DT strategy
  • 15% – implementing
  • 39% – developed
  • 23% – developing
  • 77% – use DT in IoT solution

Smart Places

  • 82% – have a DT strategy
  • 27% – implementing
  • 35% – developed
  • 22% – developing
  • 85% – use DT in IoT solution

By Industry

Smart Places

94% IoT Adopters

  • 27% – learn
  • 25% – POC
  • 25% – Purchase
  • 24% – Use

Top Benefits:

  • Increase the efficiency of operations
  • Improves safety conditions
  • Allows for better optimization of tools and equipment

Top 5 reasons for adoption:

  • Productivity enablement
  • Building safety
  • Predictive maintenance
  • Space management and optimization
  • Regulation and compliance management

Top 5 challenges

  • Still implementing current solution
  • Security risk isn’t worth it
  • Too complex to implement because of the need for business transformation
  • Want to work out exiting and future challenges before adding or using
  • Too complex to implement because of technology demands

Manufacturing

91% IoT Adopters

  • 27% – Learn
  • 26% – POC
  • 21% – Purchase
  • 26% – Use

Top Benefits

  • Increases the efficiency of operations
  • Increases production capacity
  • Reduces chance for human error

Top 5 Reasons for Adoption:

  • Quality and compliance
  • Industrial automation
  • Production flow monitoring
  • Production planning and scheduling
  • Supply chain and logistics

Top 5 Challenges to using IoT more

  • Still implementing current solution
  • Too complex to implement because of technology demands
  • Security risk isn’t worth it
  • Want to work out challenges before adding or using IoT more
  • Don’t have human resources to implement or manage

Mobility

91% IoT Adopters:

  • 30% – Learn
  • 26% – POC
  • 21% – Purchase
  • 23% – Use

Top benefits of IoT:

  • Increase efficiency of operations
  • Allows employees to be more productive
  • Improves safety conditions and increases production capacity

Top 5 Reasons for Adoption

  • Inventory tracking and warehousing
  • Manufacturing operations efficiency
  • Surveillance and safety
  • Remote commands
  • Fleet management

Top 5 challenges to using IoT More:

  • Want to work out challenges before adding or using IoT more
  • Too complex to implement because of technology demands
  • Still implementing our current solutions
  • Security risk isn’t worth it
  • Too complex to implement because of business transformation needed

Energy

80% IoT Adopters (Power and Utilities)

  • 28% – Learn
  • 26% – POC
  • 23% – Purchase
  • 23% – Use

Top Benefits

  • Increase the efficiency of operations
  • Increases production capacity
  • Allows employees to be more productive

Top 5 reasons for adoption:

  • Smart grid automation
  • Grid asset maintenance
  • Remote infrastructure maintenance
  • Smart metering
  • Workplace safety

Top Challenges:

  • Too complex because of technology demands
  • Security risk isn’t worth it
  • don’t have human resources to implement and manage

94% IoT Adopters (Oil & Gas)

  • 28% – Learn
  • 27% – POC
  • 24% – Purchase
  • 20% – Use

Top Benefits

  • Increase customer satisfaction
  • Improves business decision-making
  • Increases production capacity and the efficiency of operations

Top 5 reasons for adoption:

  • Workplace safety
  • Employee satisfaction
  • Remote infrastructure maintenance
  • Emissions monitoring and reduciton
  • Asset and predictive maintenance

Top challenges:

  • Lack of technical knowledge
  • Don’t know enough
  • Too complex to implement because of business transformation needed

Final Thoughts

Things worth noting:

  • IoT is not going away, in fact more money, time, and investment goes into it each year
  • Most organizations are looking to add AI, Edge Computing, and Digital Twins to their solutions
  • May organizations are outsourcing their IoT work and seeing more benefits because of this
  • Top challenges are around knowledge, skill, security, and implementation at scale

The original report

Posted on Leave a comment

Azure IoT Central Now Features Organizations

Now you can use IoT Central as a multi-tenant hub

Azure IoT Central now supports multi-tenant. What does this mean? It means that you as the application administrator can now manage your devices, device groups, and users under different organizations. This gives you the ability to either segment off portions of your organization or allow multiple organizations to use the same IoT Central application.

Azure IoT Central now supports multi-tenant. Segment your organization or allow multiple organizations to use your app.

What does this look like practically?

Building mltitenant solutions for… your organization

Customers in this scenario are looking for an IoT platform that allows them to provide a factory view to device managers and operators that is local to that factory. For instance, a factory operator at the West plant only sees their devices, device groups, and users. However, an administrator has visibility into all plant activity. The old way to make this work in IoT Central was to template the app and release multiple versions of it, or to use device groups as a means of organizing devices that belong to a different location. Now you can build the application once, and invite multiple locations or organizations to the application. This can also make IoT Central a manage services platform.

Building multitenant solutions for… your customers.

How is this done in IoT Central?

Devices continue to send their IoT data to a central endpoint, but on the cloud the data is segmented based on organizations.

There are three concepts at play:

  • Organizations – conceptually, it’s a container or folder where you send your device data
  • Organizations – allow for parent child relationships – parent company and child companies
  • Users – you assign users and their role or context to that organization

Personally, I’m excited about the opportunities that this offers platform developers. Smaller and mid-sized factories could share the same app and platform, but segment their data by building, zones, or even machines. This allows local operators the ability to focus on the data that is meaningful to them.

Posted on 1 Comment

Why IoT Central?

My first experience with IoT Central

Microsoft has multiple tools and services designed for IoT.

After Ignite this year it’s clear that Microsoft has dedicated a sizable investment of time and people to expanding its IoT reach. I’ve worked quite a bit with IoT Hub, Event Hub, and Azure Functions to capture telemetry data, so when I first heard about IoT Central I thought, why would I want to play with a toy version of all the bigger tools when there’s already so much on offer in Azure?

Well, I was wrong. IoT Central is far from a toy. It’s an amazing platform perfectly designed as an entry into IoT application development. I had an opportunity to work with IoT Central for our Catapult Modern Data Culture Summit and I came away with insights that I hope will show you the potential of this powerful platform.

It’s clear that no-code and low-code solutions are rising in popularity. The Microsoft Power Platform has risen to the status of the fourth cloud platform for Microsoft along with Azure, 365, and Dynamics. IoT Central is to IoT development as Power Platform is to application development. IoT Central features the same type of ease to entry and offers many of the same UI goodies developers come to expect from the Power Platform.

I’ll dive into the various pieces of IoT Central and discuss my experiences. My goal was to develop an adequate demonstration aimed at the small to midsize business interested in applying IoT to their operations. I wanted to focus on smaller organizations because I believe there’s a misconception that IoT is really only for large companies with huge budgets and a small army of IoT and data specialists. That’s not to say that IoT Central doesn’t require some technical knowledge, but the barrier to entry and the operational overhead is much smaller. If I could prove to small and midsize organization leaders that IoT Central could give them the same type of insights and observability that larger organizations achieve, but on a much smaller budget, I saw that as a great way to bring more IoT work to Catapult. It’s my opinion that almost any organization can use IoT and AI to strengthen operations, gain insights, and continuously implement total quality improvement. Could IoT Central help me prove this?

What is IoT Central?

Microsoft describes IoT Central as, “IoT Central is an IoT application platform that reduces the burden and cost of developing, managing, and maintaining enterprise-grade IoT solutions.” Unlike Microsoft’s other IoT tools, IoT Central is a web application. You log in through your IoT Central portal and create apps. These apps represent IoT solutions. By solutions, I mean a single app provides everything you need to achieve a robust IoT implementation. From the devices to the backend data, you can use a single IoT Central app to provide enterprise level products to market.

Users & Roles

IoT Central’s user management is built around a few specific roles. The documentation refers to these as personas. When planning out your implementation it’s helpful to keep in mind the type of people you’ll need to help you perform the various tasks required by IoT Central to be truly operational. You won’t need an army of specialists, but you will need a team of individuals willing to fulfill certain responsibilities.

The solution builder is primarily responsible for creating the app, configuring the rules and actions, setting up integrations with other services, and customizing the application for the rest of the various users.

The operator is your device manager. This person manages the devices attached to the application.

The administrator is responsible for adding users and assigning roles and permissions.

The device developer is responsible for writing the code that runs on the device or IoT Edge module connected to your app.

As a solution builder I found I could do everything I needed to build, deploy, and manage my IoT Central app. I could see this as a lone wolf development position at a very small company. In fact, if you’re considering an IoT solo-entrepreneur effort, IoT Central is probably a great platform to start with.

Creating the App

To get started, you need to log into the IoT Central portal. In the latest version I’m working in you are greeted with a landing page describing the service. There’s also a menu with three basic items:

  • Home
  • Build
  • My apps

Use build if you want to start an app. One thing I found most interesting were the number of templates. You can select certain solution templates based on the industries of Retail, Energy, Government, and Healthcare. Each of these presents patterns fitting for common IoT solutions. You also have the option of creating a custom app, which is where I started.

I had an idea to use a bakery vending machine as my example. My fictional company has four bakery vending machines scattered around Texas. One in Houston, Dallas, Austin, and Fort Worth. The idea was to use IoT Central is a management platform for my various vending machines. I wanted to see the following basic data:

  • Number of sales during the telemetry time period (every 15 minutes)
  • High and low temperature of the machine
  • If the machine had been serviced that day
  • Where the machine was located

One thing this demo taught me is that it’s a lot of work to prepare for a fascinating IoT demonstration. I not only needed to create simulation data and IoT device simulators for this demo, but I also needed to plan out business operations. They were actually much more complex than what I went with. I had intended to add trucks, schedule stops by fictional employees to refill the vending machines, oh lots of different things were in the works. However, time got the best of me and I had to settle for generating data for the machines and pretending some additional elements were in place.

One day in the near future I’ll spend more time creating a fictional IoT business, but what I created served my needs well enough for the demo.

Creating Devices

Unlike IoT Hub where you add a device and then assign that device ID to an actual physical device, IoT Central gives you a number of options that start at the device template creation stage. From here you can:

  • Design the device template in IoT Central and then implement its device model in the device code.
  • Create a device model using VS Code and publish the model to a repository. Implement your device code from the model and connect your device to your IoT Central app. IoT central will find the device model from the repository and create a single device template for you.
  • Create a device model using VS Code. Implement the device code from the model. Manually import the device model into your IoT Central app and then add any cloud properties, customizations, and dashboard your IoT Central app needs.

I went with the first option and created a template manually in the portal. The second choice looks like the better way to do it, and I might try that in the future. I did create a number of customizations. For instance, I ended up adding the latitude and longitude values as cloud parameters so that I could see those on a device dashboard.

Simulating the devices

I had initially wanted to use my MXChip as a device, but setting that up became non-trivial. I was just learning about the system and didn’t really have a firm understanding of how to do it. And once I started, I thought it would be a better demonstration if I had more than one device. Here’s what my code looked like:

from dotenv import load_dotenv
import sys, asyncio, os, json, time
from iotc import (
    IOTCConnectType,
    IOTCLogLevel,
    IOTCEvents,
    Command,
    CredentialsCache,
    Storage,
)
from iotc.aio import IoTCClient
from random import randint, uniform

load_dotenv()

def getPurchaseAmount():
    return randint(1,5)

def getTemperature():
    return round(uniform(8.88, 16.66))

# Load the device connection values
DEVICE_ID_AUSTIN = os.environ.get("DEVICE_ID_AUSTIN")
ID_SCOPE_AUSTIN = os.environ.get("ID_SCOPE_AUSTIN")
PRIMARY_KEY_AUSTIN = os.environ.get("PRIMARY_KEY_AUSTIN")


austin_client = IoTCClient(
    DEVICE_ID_AUSTIN,
    ID_SCOPE_AUSTIN,
    IOTCConnectType.IOTC_CONNECT_DEVICE_KEY,
    PRIMARY_KEY_AUSTIN,
    None,
    None
)
        
async def sendAustinTelemetry():
    await austin_client.connect()
    while austin_client.is_connected():
        print("client connected {}".format(austin_client._device_client.connected))
        await austin_client.send_telemetry(
            {
                "CakeInventoryFilled": 0,
                "CakeInventoryPurchased": getPurchaseAmount(),
                "FridgeTemperature": getTemperature(),
                "LocationLatitude": 30.26715,
                "LocationLongitude": -95.36327
            }
        )
        await asyncio.sleep(900)

async def main():
    await sendAustinTelemetry()

asyncio.run(main())

I used the IoTC library to make this easy. And it was. Creating the code for an IoT Central app for basic telemetry is trivial. However, I didn’t dive into cloud-to-device messaging. It would have been nice to have the ability to send a message to the machine to tell it to reset its internal inventory counter. I have more learning to do around integrating the operations side of IoT Central with a more sophisticated IoT Device. But I can definitely see the potential here.

Customization, Dashboards, Rules, and Telemetry Data

IoT Central includes a lot of tools you would need to develop yourself if you went with the traditional Azure IoT suite. You might still want to build these tools, but there was enough in IoT Central that I think you could cover the majority of your operations needs from the portal.

I explored a number of different dashboard options from device specific dashboards to sales and inventory dashboards. I was able to drag and drop tiles to represent specific telemetry or cloud parameters. If you are familiar with Power BI tiles or Azure portal tiles, you’ll recognize these UI elements. Understanding how they work is fairly intuitive. There’s not a lot of flexibility here, but if you need more than the standard set of time, you can always route data to Power BI.

You can track telemetry and add rules around the inbound data. I practiced by setting alerts based on high or low temperatures. This worked ok, but it’s by no means the sort of thing I would need to predictive analytics or something more sophisticated. If you want something more than visuals built around incoming data or custom parameters, you’ll want to integrate IoT Central with other services.

And that’s probably some of the best news. Integrating with other services is relatively easy. I connected my app to Event Hubs and captured data to send to a Stream Analytics Job. This allowed me to build a Power BI dashboard. But with a Stream Analytics Job I would perform much more elaborate rules and queries on the incoming data. You could also use the IoT Central API to build mobile apps, custom integration with lines of business like an inventory system or a telematics solution, or perform more sophisticated device management. However, I want to be clear that you don’t necessarily need to do these things. For my fictional scenario, there was really no need to create any sort of integration. I could have managed my vending machines and the surrounding services from IoT Central alone.

What about IoT Edge and AI?

I chose to stick with simple devices for my demonstration, but IoT Central definitely supports IoT Edge deployment. IoT Central treats these devices as Edge Gateways and as IoT Edge devices. IoT Central models an IoT Edge device as follows:

  • Every IoT Edge device template has a capability model
  • For each custom module in the deployment manifest, a module capability model is generated
  • A relationship is established between each module capability model and device model
  • A module capability model implements one or more module interfaces
  • Each module interface contains telemetry, properties, and commands

I like this approach to creating a device shadow that represents the IoT Edge device. It’s a good reason to implement IoT Edge devices on IoT Central.

Closing thoughts

When I first learned of IoT Central I didn’t get it. Why create a suite of Azure IoT services, and then turn around and create a little version of all these things crammed into a web app? Well, I get it now. IoT Central is far from a toy and doesn’t diminish any of the other IoT tools and services that Microsoft has to offer. If anything, It adds to that collection. I plan to explore more applications in IoT Central in the future. I’m considering it for my backyard garden’s automated irrigation system, because with so few devices and so little data, it basically cots me nothing.

Posted on Leave a comment

Thoughts on the Powel Water Leakage Case Study

Microsoft makes available many business and technical case studies based on their tools and services. I like to read through these to see how other companies have taken the challenges that IoT and cloud development present their industry specific problems.

My goal is usually to find some reusable process, approach, or thinking that I can add to my own toolbox. My latest reads were these two articles related to the municipalities in Norway that were wasting water through leakage in their water delivery systems.

The first is the basic case study that you can read here:

Using IoT to detect water leakages with Powel

Basically, this is your standard monitoring IoT pattern with some ML anomaly detection baked in to help alert operators of possible leaks. The team did face a few unique challenges in developing this solution.

SCADA systems

Most of the telemetry device data came from SCADA (supervisory control and data acquisition), which I did a little of my own research on to get a better understanding of these types of systems actually work in municipal water suppliers.

The following gives a pretty good overview:

StackPath

There’s an interesting section in the above article that explains how telemetry data is viewed and how alerts are set up.

“The HMI is configured to alarm on a number of I/O point readings. By defining “normal” or “safe” operational states for specific I/O points, if conditions ever deviate from those parameters, the control center receives a visual alarm. The alarms are also integrated into a pager system and an on-call operator receives a cell phone message that they acknowledge and handle appropriately.“

To me, this is where the value of connecting a more versatile tool like Azure IoT Hub comes in. How do you go about defining the normal or safe operating parameters?

As is discussed in the DevOps article associated with the Powel use case (the second article I mentioned earlier), you can use machine learning to analyze the data and determine anomalies in the water flow, such as fire hydrant usage, leaks, or other unusual water flow conditions.

Using IoT to detect water leakages with Powel

This case study has a lot to learn from, and here are some of the thoughts I had while reading through.

The Architecture

Overall, I like that Azure IoT is an integration piece to the existing SCADA system. Instead of attempting to replace that investment, the team was able to piggyback on that solution by creating gateways from the SCADA system to Azure IoT Hub and the rest of their Azure platform. Azure here is a supplement to their existing system allowing the team to bring the SCADA system’s telemetry data to be captured, run through data insights, and used to train machine learning to search for the type of anomalies that indicate water leaks.

I like the choice of micro services to provide access to the various slices of the system. They are using an API stack to integrate multiple data views into a Single Page Application for their tenants.

— my suggested next steps

As I read through this I kept thinking that the next steps needs to be to move some of that anomaly detection closer together the source. Unless there’s a pressing need to capture all the SCADA system telemetry, it makes sense to me to convert the SCADA gateways into IoT Edge devices that can host the anomaly detection algorithms outside IoT Hub serving as a filter to block telemetry data that is considered normal.

DevOps

I think there a great tools available to help in the initial planning stage of a big project. Value Stream Mapping and a Hack-a-thon were a great place to start. From these two events the team learned a lot of lessons quickly, which should be the goal at the outset of a large project. Learn fast while building something that informs your stockholders and solidifies your goals.

Discipline in the DevOps approach was another great thing to see the team take on. Security was top of mind, while production first delivery was something the team struggled with, adapting that mindset allowed them to almost double their productivity.

Their Approach to Machine Learning

They used Power BI as their initial data analysis tool. Typically, they would have used Python and visualization tools in a Jupyter notebook to do their data analysis, but this team took advantage of the out-of-box visualization and integration with Stream Analytics Services to make some of their initial decisions.

Machine Learning Studio was their machine learning environment of choice. Using it in combination with Power BI to discover anomalies, experiment with features and algorithms, and produce the solution was a great use of Azure’s IoT suite.

The most amazing thing about this case study is that Powel was able to achieve a tremendous amount of value in as little as 5 days.

My biggest takeaway

1 – Azure IoT plays exceptionally well with others. Gutting a legacy IoT system to replace it with Azure IoT isn’t necessary. Azure IoT could expand your legacy capabilities without losing that initial asset.

2 – Just because you’re developing a fast POC or MVP doesn’t mean you shouldn’t think security and production first. In fact, I want to see what I can use from the initial DevOps list and apply it to my own projects.

This was their DevOps discipline:

  • Underwent a value stream mapping session to find areas of improvement.
  • Created a multi-team project with work flowing from one team to the next.
  • Used a microservice approach to deliver software updates in a “fast ring” style without downtime.
  • Defined acceptance criteria according to the ISO standards for software quality.
  • Used the SDL and the Microsoft Threat Modeling tool to assess security risks early.
  • Architected the code using Domain-Driven Design (DDD) principles.
  • Used a long-lived feature branching strategy, using Git as source control.
  • Adhered to the SOLID principles of object-oriented design.
  • Developed code using a Test-Driven Development (TDD) approach.
  • Set up an automated build and test pipeline for each component of the solution (CI).
  • Set up release management (CD+RM).
  • Used A/B testing based on an opt-in policy.
  • Expected to monitor running applications using Application Insights.
  • Used Infrastructure as Code.
  • Used Slack as a collaboration tool between departments.

We worked long and hard during each day of the hackfest. Everyone was high-spirited and excited about the work, and when Friday afternoon came, we had a working proof of concept (POC) tying in all of the API components with the Web App and output from the Machine Learning algorithm.“

Overall, this was a great case study to learn how Azure can work with existing telemetry gathering networks to bring modern tools and practices to legacy IoT systems.

Posted on Leave a comment

Create an Azure IoT Security module Twin

What are these things and why do we need them?

The twinning concept is one of the cooler things to come about lately. Not only can you digitally twin IoT or IoT Edge devices, but you can also twin environments, and I’m sure eventually we’ll be twinning all sorts of things like industrial equipment, trains, planes, automobiles. Basically, anything that fog computing devices need to work with can be twinned, including the actual fog computing device.

To understand what a module twin is, we need to also understand what a device twin is and what purpose it serves in Azure’s IoT Hub.

Device Twins are basically json documents that represent a device. They store metadata, configuration information, conditions, and basically represent the state of that device.

One thing to note, this is only available in the Standard tier of IoT Hub (and Free), but not in Basic. That’s because Basic doesn’t provide for two way communication. Basic only allows IoT Hub to receive telemetry data. One way communication. Standard however will allow IoT Hub and the device to maintain two way communication. If you plan to practice building out more sophisticated IoT devices, especially the AIoT or Edge devices, you will need to use Standard tier.

A device twin has this structure:

  1. Tags
  2. Desired properties
  3. Reported properties

And you’ll use the device twins to do the following operations:

  1. Synchronize workflows between devices and the backend systems
  2. Store device specific meta-data in the cloud
  3. Report on state
  4. Query the device for metadata, state, or configuration

There’s recommendations on how that communication should transpire, but I won’t go into that in this post.

It’s just import to remember that device twins store device information that allows the device and the backend to synchronize configuration and conditions and that the solution back end can query long running operations.

Device Twins also have a lifecycle. This is linked to the device identity. Twins are created and deleted when a device identity is created or deleted in the IoT Hub.

The json document includes the following elements; tags, desired properties, reported properties, and device identity properties.

I won’t go into detail on these, but they can be used to manage various aspects of the device. There are also a number of back end operations like; retrieve device by twin id, partially update device twin, replace desired property, replace tags, and get notifications from the device – this is managed with a twinChangeEvent.

Operations that can be performed on a device are

  1. Retrieve device twin
  2. Partially update reported properties
  3. Observe desired properties

Devices preserve their desired properties when connecting to IoT hub if their device twin version is the same. However, if the version has incremented it will retrieve the full json document to get the desired properties.

How does this relate to module twins in the IoT Hub? What is a module twin?

When you create a device identity and IoT Hub creates a device twin, under that device twin you can create up to 50 module identities.

These represent a sub-section of the device. For instance, if I have a Raspberry Pi with a moisture detector, a light detector, and a temperature detector, I can make these all modules under the device identity I’ve assigned the Raspberry Pi.

Module twins are nearly identical in form and function as their parent device twin. I can also assign different security profiles to a module twin and grant access to it to different groups. This means that certain members of my team can see the moisture information, others can see the temperature, and yet another group could see the light information (probably no real reason to do this in the real world with this particular device, but the capability is there).

How do we create a azureiotsecurity module twin?

  1. You can actually create a module batch script that will automatically create module twins any time a new device twin is created.
  2. You can also manually create them.

To manually create a new azureiotsecurity module twin for a device use the following instructions:

  1. In your IoT Hub, locate and select the device you wish to create a security module twin for.
  2. Click on your device, and then on Add module identity.
  3. In the Module Identity Name field, enter azureiotsecurity.
  4. Click Save.

Boom! That’s all you need to do. When you review your existing modules for the device, you should find on there titled, azureiotsecurity.

Posted on 4 Comments

Azure IoT Custom Security Alerts

I love that IoT Hub makes it easy to add custom alerts. You can also manage these alerts for groups of devices, instead of attempting to create them one at a time. These alerts allow you to build specific rules for these groups of devices that best fit the use case of the device.

The following the recommended method for setting these up in the portal. I’m still searching for a way to do this with Azure CLI, but when I find it I’ll post an update.

Because you as the developer will know your devices best and understand what sort of alerts you need to create for your device parameters, Azure Security Center provides a way for you to develop device behavior policies and alerts.

What are security groups?

Security groups are a logical way to maintain devices by tags. You choose how those devices are categorized. It could be by hardware type, region, or whatever best fits your particular domain needs.

This is tagged in the device twin settings under the tags property of “SecurityGroup,” and comes with a value of “Default”

After creating a group, you can assign custom alerts.

How do you customize an alert?

  1. On your IoT Hub Security section, open the Settings
  2. Click custom alerts
  3. If you haven’t, create a device security group
  4. Click on the new security group
  5. Click Create custom alert rule
  6. Select a rule from the list

You can find a list of customizable security alerts here:

Customizable security alerts – Azure Security Center for IoT

Set your parameters for the rule.

For example, I selected the custom alert for “Login by a local user that isn’t allowed,” and added an email for paul@raspberrypitestdevice.com.

Save the new rule. Continue this process for each group and each rule.