Dataworks as a company had been involved in a number of discussions in recent times with our customer base regarding IoT (Internet of Things) and collecting and streaming data to the cloud. Normally our input into the development of these IoT solutions would stop at the source device and as a consequence we were only conceptually aware of what is involved at the device level. We decided to change that by doing an internal proof of concept (POC) where we would take an off the shelf embedded system and get it to stream its sensor data to the Azure cloud. The aim was to give us a more rounded understanding of the entire IoT data chain. This article describes how we did this and what we learned from this exercise.
What is IoT
Anyone who has got this far into the article will probably already be very familiar with the term IoT. Even still, we wanted to include a definition in this blog which best described IoT from the perspective of our POC and found the following which we believe does this quite well.
“IoT is a network of physical devices, containing embedded systems with network connectivity which enable these devices to collect and exchange data”
POC Data Sources
We looked for some relevant data sources to use in our POC and settled on environmental data (temperature and humidity) as one of our source types. This is something that is often of interest in a manufacturing context where process engineering look to correlate environmental conditions with production metrics such as yield. We also wanted to use some faster moving data to show the real time capabilities of Azure. Accelerometer and Gyroscopic data were included in our source types for that reason.
Having had some experience of working with ST Microcontrollers in the past it seemed like the natural place to start our search for a suitable device for our POC. ST offered a solution which was exactly what we required. The P-Nucleo-CLD1 (shown below) is an evaluation kit which, as well as providing the necessary hardware (temperature and humidity sensors, accelerometer and gyroscope along with WiFi), came with full source code for the IoT solution. For the remainder of this blog we will refer to this as the ‘device’ for simplicity.
Cloud Solution Provider Selection
The selection of Microsoft Azure Cloud Solution was a straight forward decision for a cloud solution provider, given Dataworks long history of developing solutions using Microsoft technologies. Azure’s IoT Hub is a fully managed service that enables reliable and secure bidirectional communications between millions of IoT devices and a solution back end and was the final piece of our POC puzzle.
Microsoft Azure Applications
As well as the IoT hub, which would manage our IoT device, we wanted to explore other Azure applications which would showcase the kind of things you could do with a device which steamed data to the cloud.
Azures Stream Analytics was the first application that we wanted to look at. Stream Analytics performs actions on real-time data, such as updating an external database with processed information. The significance of this application deserves emphasis. Traditionally a solution for monitoring a data stream might involve taking all incoming data and writing this data to a repository such as a database. Periodic queries would then be run on the data repository to look for a specific type of event. Obviously an application like Stream Analytics, which acts on the incoming data stream has huge advantages over the traditional solution in terms of storage and response time and is a vital tool in any IoT solution.
Azure provides a number of cloud data storage options. For our POC we chose a SQL server database as the destination for our streaming data.
Time Series Insights was the final Azure application that we felt required was worth looking at in an IoT context. It is used to visualise the data being streamed from our IoT device and gave a tangible demonstration of the power of IoT.
Linking our Device to Azure IoT Hub
With all the hardware and software selected the next step was to integrate the various pieces into our IoT solution. To begin, we setup an Azure cloud account and created the IoT Hub which would be the destination for our streaming data and would also be the source to which our Azure storage and analytics applications would connect. The screenshot below shows the IoT Hub setup screen and the highlighted section in the bottom right hand corner contains the connection string which uniquely identifies our IoT hub.
Microsoft conveniently provide a desktop application called Device Explorer which allows you to setup your device to connect to your Azure IoT hub. It also provides some diagnostic and interrogation tools for use with your configured device. The screenshot below shows the configuration tab of Device Explorer where the IoT Hub connection string from above is entered.
Once this is entered your specific device is created under the management tab (screenshot below) and the ‘Copy connection string for selected device’ option is selected which provides the string which will be used by your device to make the connection by it to the IoT hub.
The source code provided with our device from ST does not have any knowledge of our specific IoT hub so this information needs to be edited into this source and the demo project needs to be rebuilt with the connection string from Device Explorer. We used the free System Workbench compiler from ST to perform the build and the free programming software STM32 ST-LINK to program the microcontroller in the device.
The screenshot below shows the sections in the include file where our specific device connection string was added and the setup of our specific wireless network which the device will use to connect to Azure.
The ST-LINK programming utility (screenshot below) takes the bin file created by System Workbench and programs the microcontroller via the USB port on the board.
Testing the device connection to your Azure IoT Hub
In most embedded systems, where a display or keyboard is not provided as part of the solution, an alternative Input/Output method is required. When we connected our device to our PC via USB it automatically sets up a virtual serial communication port through which board diagnostic information could be displayed. We used the serial port terminal application Tera Term to connect to our device. Configuring Tera Term with the following serial port properties allows the device to output its setup and diagnostic information and for the user to confirm that the connection to your Azure IoT hub has been successfully made.
The following screen shots show the information output via the virtual serial port after device reset. The first shows the results of internal tests on the device hardware and software.
The screenshot below shows the connection being made to the default wireless network we programmed into the device. You can see there is also a method to alter this connection via a button on the device and data input via Tera Term.
The final screenshot below shows the IoT hub connection being made and a message being output every time a sample is sent to the IoT Hub.