Azure IoT Central

IoT Central is accessible through a Microsoft web site at https://​azure.​microsoft.​com/​services/​iot-central. The web site heading is pictured in Figure 6-1. This site provides the links and information you need to get started.

When you are ready to build your first application and initially enter IoT Central, you’ll be presented with the screen shown in Figure 6-2.

You can try IoT Central for free for the first 7 days or choose to pay as you go. Then you select an application template from samples that are provided or define your own custom application. If new to IoT Central, you might choose to deploy the Contoso sample template that Microsoft provides so that you can gain familiarity with the subsequent interfaces.

We’ve selected creating a custom application in the previous figure. We also gave the application a name, noted the URL assigned, and provided appropriate billing information. The following dashboard and options are then presented as shown in Figure 6-3.

Choosing to create device templates, we next define our device measurements (telemetry, state, event, and location), settings for devices (numbers, text, date, toggle, section labels), properties (such as device, customer, and service information), commands that remotely manage devices, rules that trigger actions when certain monitored conditions arise, and the dashboards for our devices. The interface to do this in IoT Central, including the measurements that can be created, is shown in Figure 6-4.

Once a new device type is defined in a template, we can add the device using the device explorer in the interface. We enter the device ID and device name and then adjust settings and provide property information as needed. Next, we generate a connection string for the device, prepare a Node.js project associated with the device, and then configure the client code.

For purposes of illustrating what a deployed solution looks like, we’ve created the Contoso sample application that gathers data from simulated refrigerated vending machines. If you choose to create that sample application, your dashboard should appear like the image shown in Figure 6-5. There are options to view just devices with active maintenance contracts, just the devices located in Seattle, add a device set to group the devices in another way, or view all devices.

On the menu along the left side, in addition to viewing the dashboard, we can access device explorer, device sets, analytics, and jobs. We also see access to device templates, continuous data export, and administration.

In the sample application, if we access device explorer and look at the measurements for one of the devices, we’ll see telemetry measurements being tracked on the left (including accelerometers, gyroscopes, humidity, magnetometer, pressure, and temperature). We also see the time series display of recent measurements tracked in the chart on the right as shown in Figure 6-6.

The dashboard in device explorer consists of customizable views of a device. For the same refrigerated vending machine in our example, the dashboard is set up to show machine information; anti-tampering information based on data from the accelerometers; maximum temperature, average pressure, and minimum humidity readings; and a chart of environmental trending over time of humidity, temperature, and pressure. That dashboard is shown in Figure 6-7.

In device sets, we find the device set names, their descriptions, and the device template used. We can set conditions for device sets by selecting properties (such as location, temperature alerts, fan speed, etc.), an operator (value for the property equals, does not equal, is greater than, is greater than or equal to, is less than, is less than, is equal to, contains, etc.), and a value. We can also view individual devices within each device set. Here, we can view measurements, settings, properties, commands, rules, and the dashboard for each device. For example, we might set a rule that an alert is sent if the device is moved more than a certain distance.

In analytics, we choose the device set we want to apply analytics to; set a filter on a measurement including a condition, operator, and value (similar to device sets approach); define a time period we want to look at (from 10 minutes to last month to custom); and then show results. Figure 6-8 shows a view of analytics performed based on filtering applied to temperature readings.

Jobs can be created to set device properties or settings. We begin by defining a job name and providing a description and device set to use. We define whether the job type is aligned to device properties or settings and then select a property or setting and provide a value. Figure 6-9 shows setting up a job to set fan speed in a couple of the refrigerated vending machines in a defined group (i.e., those that are in Seattle).

Functions below the line on the left side of the application interface in the previous figures are focused on setup and management. These include access to setting up device templates (previously introduced), continuous data export, and administration.

When creating a new device template, you can create a custom template or utilize one of those that Microsoft provides as shown in Figure 6-10. A new device template is created as version 1.0.0.

If you later make changes to settings or required properties in the device template, you will be prompted to create a new version. This can be extremely useful as you might initially find that rules are broken in the new version, such as when properties that conditions rely upon have been removed. Some of the tiles in your dashboard might also be broken if properties or settings are removed. While you fix these problems, operators will still have access to the old fully working version. When you are ready, you can migrate devices to the new version through device explorer.

Continuous data export enables you to export data from IoT Central to your storage. (i.e., Azure Blob Storage, Azure Event Hubs, Azure Service Bus). The administration interface enables management of application settings, users, roles, billing, device connection, access tokens, application customization, help customization, and application template export.

IoT Solution Accelerators

The IoT solution accelerators are designed to speed implementation of popular IoT scenarios, such as those for remote monitoring, connected factories, and predictive maintenance, by automatically provisioning key PaaS Azure cloud services needed in each scenario. Microsoft positions the solution accelerators as starting points for your own IoT solutions. They are designed to be scalable, modular, understandable, extensible, and secure.

At the time this book was published, Microsoft was in the process of moving the solution accelerators from a model-view-controller (MVC) architecture written in .NET to a microservices architecture. A microservices architecture can improve the flexibility, reliability, and scalability of a solution. The Remote Monitoring and Device Simulation solution accelerators were already deployable in a microservices architecture when this book was written.

The underlying code in the solution accelerators is open source and available on GitHub. For customization of backends, you will need Java or .NET skills. Visualizations can be customized using JavaScript.

You likely will begin exploring the Azure IoT solution accelerators through the Microsoft web site at https://azure.microsoft.com/features/iot-accelerators. Figure 6-11 shows the web site heading.

Figure 6-12 shows the four solution accelerators on the home page. By choosing links in this interface, you can provision each of the services. If you prefer, you can also deploy the solution accelerators from the command line. For solution accelerators other than Device Simulation, there is also a link to try a demo of the solution. The demos can be particularly useful when you want to explore the capabilities that these solution accelerators provide.

Next, we’ll explore each of the IoT solution accelerators regarding their capabilities and key resources that are provisioned.

Remote Monitoring

The Remote Monitoring solution accelerator enables collection of telemetry from multiple devices in remote locations. A dashboard shows the telemetry from the devices and provides an interface used to provision new devices or upgrade device firmware.

When you deploy the Remote Monitoring solution accelerator, you have a choice of standard, basic, or local configurations. The standard configuration is intended for production and deploys microservices on several Azure virtual machines. The basic configuration is intended for testing and demos and deploys the microservices on a single Azure virtual machine. The local virtual machine deployment is intended for testing and development and connects to the Azure IoT Hub to reach cloud resources.

Automated provisioning provided by the Remote Monitoring Solution Accelerator generates, creates, and configures the activities used in setting up the needed cloud services. These activities appear in Figure 6-13. In our example, we built the basic configuration.

The Azure cloud services started in the resource group that are created are shown in Figure 6-14. Among the key resources made available is the single virtual machine for the microservices, the Azure IoT Hub, Cosmos DB, storage accounts, Time Series Insights, Azure Maps, Stream Analytics job, Event Hub, Logic App, and Apps Services. Microservices in this solution include an IoT Hub Manager microservice, device telemetry microservice, storage adapter microservice, Azure Stream Analytics manager microservice, and device simulation microservice.

When using the Remote Monitoring solution accelerator for demos (along with the supplied simulated device data), you can explore readings from a variety of chillers, elevators, engines, trucks, and prototypes. The main dashboard is shown in Figure 6-15.

You can see that the dashboard leverages Azure Maps to display where the devices are located. Integration with Time Series Insights (e.g., the menu shown on the left in the figure) is evident.

Predictive Maintenance

The Predictive Maintenance solution accelerator uses machine learning algorithms applied to device telemetry data to predict when the devices will fail. This solution can be used to put into practice optimal device maintenance plans and activities.

Automated provisioning provided by the Predictive Maintenance solution accelerator generates, creates, and configures the activities used in setting up the needed cloud services. These activities appear in Figure 6-16.

The Azure cloud services started in the resource group that are created are shown in Figure 6-17. Key resources made available include the Azure IoT Hub, storage accounts, a Machine Learning Studio workspace, Stream Analytics job, Event Hub, and Apps services. The Stream Analytics job first selects all device telemetry and sends data to blob storage for visualization and then computes average sensor values over 2-minute sliding windows (sending this data through an Event Hub to an event processor).

Once provisioned, a link is provided to the Machine Learning Studio and the workspace.

Figure 6-18 shows a view of a model provided for demonstration purposes that includes a regression algorithm developed by Microsoft using a public sample data set that contains telemetry coming from sensors in jet engines.

The Predictive Maintenance solution accelerator also includes a demo dashboard for the same sample data set. The regression algorithm that is deployed predicts the Remaining Useful Life (RUL) of the two jet engines as data from four sensors in each engine is cycled through. Each cycle denoted in the dashboard represents a flight of 2 to 10 hours. Data is captured by sensors every 30 minutes during a flight.

Figure 6-19 shows the RUL dashboard displaying these KPIs including charts of recent readings and predictions.

Connected Factory

Security permissions for users are configured based on role-based access control (RBAC) . End-to-end encryption is implemented using OPC UA authentication (X.509 certificates) and security tokens.

Automated provisioning provided by the Connect Factory solution accelerator generates, creates, and configures the activities used in setting up the needed cloud services. These activities appear in Figure 6-20.

The Azure cloud services started in the resource group that are created are shown in Figure 6-21. Key resources made available include the Azure IoT Hub, Cosmos DB, storage accounts, Time Series Insights, Azure Maps, Event Hub, and Apps Services.

A demonstration dashboard is provided with simulated device data that can help you better understand the functionality provided. A map provides a view of where factories are located. The status of each factory is shown as is a list of current alarms. Overall equipment efficiency, availability, performance, quality, units per hour, and kWh are represented by indicators. You can then drill to further detail through the dashboard.

Figure 6-22 shows a couple of the radial gauge charts presented in the dashboard.

Device Simulation

The Device Simulation solution accelerator is designed to define simulated devices that create realistic telemetry. The telemetry can then be used in testing IoT solutions that you are developing. The modeling includes message formats, twin properties, and methods. More complex device behaviors can be simulated using JavaScript.

You can simulate a single device during testing or scale the testing to thousands of devices connected to your IoT Hub(s). So, you can simulate normal, peak, and extreme workloads for scale testing.

Automated provisioning provided by the Device Simulation solution accelerator generates, creates, and configures the activities used in setting up the needed cloud services. These activities appear in Figure 6-23.

The Azure cloud services started in the resource group that are created are shown in Figure 6-24. Key resources made available include the Azure IoT Hub, the Cosmos DB, the storage accounts, and the application services.

Once provisioned, you can run the sample simulations provided (including good and faulty chillers, elevators, engines, trucks, and prototypes). You can also choose to define custom device simulations including data points and value ranges. As noted earlier, your third choice is to create advanced device simulations in JSON definition files using JavaScript that you can upload.

A sample dashboard is provided to view the simulations and provides information on the number of devices, the total messages and message rate, the number of failed messages, the number of device connections, and the number of failed twin updates.