Azure’s Secret Weapon for Industry 4.0

Automatic Digital twins, Machine learning with no data cleaning and more..

In a previous article I compared an IIOT architecture to a meeting room where everyone is present and exchanging ideas in real time using the same language. One of the “languages” that can be used for this purpose is SparkplugB. Previously, AWS was the only cloud provider that could speak this “language” but this changed in September 2022 when Azure announced IOT Bridge for Azure. Refer to the article below:
Product News: Cirrus Link’s IoT Bridge to connect OT data to Microsoft Azure | Smart Industry

The implications of this is massive.

Azure can now spin up a digital twin in half and hour and create machine learning models immediately without the need to clean or standardize the data. What used to take months can now take weeks. How is this possible?

Inductive Automation, the company that created the popular MQTT broker (Ignition), created the IOT Bridge for Azure that can be used by Azure to automatically consume all the data models that live in the broker namespace. Let me break this down a little bit more by defining what a data model is, what it looks like in Ignition and how it is consumed by Azure.

Photo by Simon Kadula on Unsplash

What are Data models?

A data model in this context is a data template representing a physical asset. Metadata like unit of measure can be defined in the template. For example, here’s what a data model for a Motor can look like:

Motor Model

• RPM
• Temperature
• Voltage

For any of the parameters ex- Voltage, a unit of measure (Volts) can be defined within this data model.

In Ignition, this manifests in the form of a User Defined Template (UDT). See screenshots from my Ignition instance below:

Motor — User Defined Template

Motor — User Defined Template Definition Editor

Any tags in the broker ex — IOT data can be mapped easily to these data models in Ignition.

How are these Data models consumed by Azure?

This is where the IOT Bridge for Azure comes in. In essence, it is a virtual machine with specific configurations that create a connection between an Ignition MQTT broker and Azure Digital Twin. The Azure Digital Twin data can be historized in Azure’s powerful time series database, Azure Data Explorer.

Here is the architecture:

The configuration of this architecture is simple. It takes 30–45 minutes to deploy all the pieces in Azure. Once finished, you will be able to see all your asset models appear in Azure Digital Twin. Here are a few screenshots from the instance I spun up:

Azure Digital Twin: Notice the data models were automatically detected on the left

Azure Digital Twin: Clicking on a node allows you to see all its properties

The second screenshot shows data from one of the conveyors I had configured using a conveyor data model. There were no data cleaning or data transformation pipelines required to bring this data with context into Azure. This is extremely exciting!

In the next step of the architecture, the data from the Digital Twin is historized in Azure Data Explorer and can be queried using the Kusto Query Language:

Again, regardless of the source of this data — SAP ERP , a Siemens S7–1200 PLC or even an Arduino, all the data is formatted in the same way and is ready for analysis. Interested in predictive maintenance? Azure Data Explorer has a built in anomaly detection query among many other solutions.

In many situations, Industries require the result of a Machine learning model to be sent back to the applications on the plant floor to perform functions such as setting off SCADA alarms or issuing a work order from a maintenance management system. This is possible in Azure. An Azure function can be created to query Azure Data Explorer and send the result of the query to a broker. (Ideally hosted in the cloud to satisfy the Purdue model of Industrial cybersecurity). If the Machine learning model is built using an application like Azure Machine learning, the model can be deployed as a web service on Azure IOT Edge which the broker can then send requests to to get the result of the machine learning model.

Implications

Here are some of the possibilities that this architecture can open up:

• Remove the need for Data Engineering pipelines: In order to clean Industrial Data, many cloud solutions use a Data Warehousing architecture (ex — Kimball architecture). This involves dumping data in a data lake and then creating pipelines to clean and transform the data before it is ready for insights. This is a batch process which means that the data is never available in real time. In this architecture, the data model is auto-discovered in Azure and is immediately ready for insights with no data processing required!
• Reporting Solutions can be delivered faster: Azure Data Explorer has built in Integration with PowerBI, a phenomenal visualization platform offered by Azure. This can lead to faster development of reporting solutions since no data cleaning is necessary. It will also enable near real time data to be reported.
• Machine Learning Solutions can be delivered faster: Besides Azure Data Explorer’s anomaly detection capabilities, it offers plugins for clustering, seasonality detection and regression algorithms. It also provides built-in integration with Azure Machine Learning, Microsoft’s cloud-based platform for building, deploying, and managing machine learning models. This integration enables users to leverage a rich set of algorithms and models to build predictive models, conduct sentiment analysis, and perform other machine learning tasks.
• Support an architecture where the data model is defined at the edge: In so many cloud solutions, the data model is defined in the cloud. This is a shame because there are so many applications on the plant floor/mine site that cannot use this data model ex — ERP, MES, SCADA, historians etc. Instead each create their own data model which leads to data being defined differently in different applications. If an application becomes redundant and needs to be replaced, the effort to create the data model needs to begin again (this could take months). In this architecture, the data model is defined at the edge (MQTT Broker) and not the cloud. Azure is just a node in the ecosystem and can easily be replaced if necessary. A company is not trapped with PowerBI in case something better comes along.

With IOT Bridge for Azure, Azure has shown that it possible to deploy a digital twin in less than an hour and create machine learning algorithms and visualizations with no data cleaning. This reduces the time to insight significantly and I am excited to see what industries do with this architecture.