Intercept of Things - part 2: Planning your IoT Solution

The device

First things first. What kind of IoT solution are you going to offer? Are you going to gather telemetry like temperature, humidity, and possibly motion, are you going to run an object detection solution that analyzes video real time or maybe your operating machinery connected to the cloud?

That is a lot of questions and to each their own use case, but it is important to decide up front what your solution will do, what kind of data it will generate and how much of that data needs to be sent to the cloud. Additionally, how much processing needs to happen at the location itself? This will determine the kind of hardware you need. It is obvious that video and image processing takes up a lot more resources on a device than simply gathering temperature data.

Data

Those devices will generate data. That data needs to go somewhere. If we look at Azure IoT Hub it can take in a lot (and I mean a lot) of data and sink it into pretty much any relevant Azure Service using the built in connectors or by using a custom Logic App’s or Azure Function’s.

Even though building a quick proof of concept and generating some data will give you a good idea of how much data a device will generate but when it comes to IoT you need to think about what happens when the solution scales.

What if you are developing a solution to gather telemetry from different sensors like temperature, humidity and motion but also provides the ability to switch lights on and off. You develop that for a single office space in a building as a proof of concept. What if this is installed in every office and you are now dealing with thousands of sensors. That is quite some data that needs to be transferred. But the amount of data that can be transferred simultaneously really depends on the connectivity and how often you need new telemetry from the devices (once per second or once per hour is quite the difference here!).

Connectivity

Once you know what kind of data you are going to generate and how much you need to store in the cloud it is time to look at the connectivity. Some factors are important here:

• Location and internet connectivity of the site where the device(s) will run
• The amount of data you want to send to IoT Hub
• The interval (when do you want to send data)
• Do you just need to send message to the cloud (Device-to-cloud messages), or do you want to send Cloud-to-Device messages as well?

Now is the time to make some choices. Specifically for the protocol you want to use and the infrastructure at office building.  

When it comes to Azure IoT Hub we have 3 flavors:

• AMQP
• MQTT
• HTTPS
  
  

Note that AMQP and MQTT are also supported over web sockets (port 443). Now it’s time to make some decisions

And here’s the catch. What if your solution requires a different protocol? Maybe you’re using ModBus or have your own proprietary protocol? Not all is lost. We can use an IoT Edge Gateway to perform the translation to a supported protocol. We do have to keep in mind that IoT Hub will not have the actual devices “configured” but instead receives the data from the gateway. This means that you will need an identifier for the device in your messages to make sure you know which data came from which device at a later stage. You will also see similar configurations (even if your end devices support MQTT or AMQP) if you choose to send the information in batches and you don’t need real time data accessible from the cloud.

There is much to be said on how to go about picking the right protocol for you, but this should illustrate your general options and how to go from there. Also keep an eye out for quotas and throttling on IoT Hub to make sure your solution performs as expected.

Processing the data

The next question is: where will data processing take place? Will all devices send data directly to IoT Hub or do you require pre-processing or complete processing on the site/device itself? Connecting the device directly to Azure IoT Hub is pretty straight forward using the already available SDKs (or using HTTPS if that is your use case).

But what about that processing on the device itself? Let’s say that your office building also has security cameras that you want to use for object detection or face recognition. This is when the term “Azure IoT Edge” comes into play. I will do a detailed post on IoT Edge later in the series but it’s important to understand the concept when you are planning your solution. IoT Edge consists of a runtime that runs on the devices and can manage multiple docker compatible containers. We call these “modules”. These modules contain the code you need for processing. If we look at the office building example, one of the modules could be a classification module containing a PyTorch model you created. A second module would then be a container that captures the camera stream and sends it to the classification module for processing. Only the results (for instance: Person A or B) will be sent to IoT Hub using the cloud interface that comes with IoT Edge.

Do note, that this takes a considerable amount of processing power compared to sending telemetry from temperature or humidity sensors.

Knowing where you want to process data is important before you start building your solution.

Provisioning

Last but not least, we need to provision a device. One way to provision a device is to use the SDKs, add the connection string for the device or gateway and start sending data to Azure IoT Hub. That’s pretty straight forward but if you’re using a proper authentication method such as certificates then it’s a task you probably don’t want to perform for thousands of devices. And what if you’re using multiple IoT Hubs and want to load balance traffic across them? This is when the Azure IoT Hub Device Provisioning Service is going to be your super hero.

DPS allows you to configure an enrollment and all you will have to do is point the device at the provisioning service. It takes away the problem of performing multiple actions on the device before it connects to IoT Hub. Usually not a problem for a couple of devices but you will regret not looking into DPS when you scale to hundreds of devices.

What's next?

In the next blog we will talk about device messaging and how you could go about interacting with the device and routing messages to the right endpoints. Stay tuned!

This article is part of a series 

Read the introduction of IoT here!