MQTT-Based Manufacturing Reference Architectures Using HiveMQ on Azure

Microsoft Azure is widely considered to be one of the top two cloud platforms, along with AWS. Azure is also considered the top cloud platform for IoT applications. At HiveMQ, customers deploy their IoT applications on Azure to take advantage of Azure enterprise services, such as machine learning, analytics, dashboarding, storage, etc. However, to ingest IoT data to the Azure platform they use HiveMQ on Azure. This white paper discusses manufacturing reference architectures and use cases, specifically for inter factory connectivity scenarios, and shows how customers can use HiveMQ to connect the data of different factories to the Azure Cloud to achieve different data consumption.

The manufacturing use cases we are going to discuss in this whitepaper can be classified into two categories; Hot Path use cases and Cold Path use cases. Hot Path uses cases are where data needs to be consumed, processed and visualized in near real-time. In Cold Path use cases the data is needed for more longer term and non time critical analysis.

Manufacturing Reference Architectures for Hot Path Use Cases

Inter Factory Data Correlation using MQTT and Azure

When factory process engineers want to analyze process data across factories to make running changes, they can do so by correlating/performing data analysis of process data across factories. For this to happen, the factory Performance Data could flow through the HiveMQ Broker on cloud to Azure where it can be ingested using Azure Event Hubs and then analyzed using Azure Data Explorer. Below is the architecture for the same.

There are two major advantages to using a HiveMQ broker on the cloud in this scenario. The first is that it provides a very scalable solution with load balancers to balance the load of the process data flowing in from different factory systems (MES, DB, Historians) that could be in different regions of the world. Secondly, it offers tools to provide a high level of factory IoT data observability and transparency to overcome any data bottlenecks going to the cloud or coming back to the factory.

Remote Anomaly Detection in Factory Machines with MQTT and Azure

Data Scientists would like to detect anomalies in factory machines to take corrective actions. They can do this by applying machine learning modeling of machine data across factories. For this to happen, there are multiple ways to do it on Azure. First way could be for the Factory Machine Data to flow through the HiveMQ Broker on cloud to Azure where it can be ingested using Azure Event Hubs, explored on Azure Data Explorer and visualized on Power BI. A second way could be for the Factory Machine data to flow through the HiveMQ Broker on cloud to Azure where it can be ingested using Azure Event Hubs, analyzed on Azure Streaming Analytics and visualized on Power BI. A third way could be for the factory machine data to flow through the HiveMQ Broker on cloud to Azure where it can be ingested using Azure Event Hubs, analyzed through a special program written on a serverless Azure function and then a Twilio service could be used for the notification. Below is the architecture for these options.

There are two major advantages to using a HiveMQ broker on the cloud in this scenario. First is that it provides a very scalable solution with load balancers to balance the load of the data flowing in from different factory machines that could be in different regions of the world. Second is that it offers tools to provide the high level of factory IoT data observability required to ensure that there is transparency in case there are any bottlenecks coming into the factory or at the cloud level.

MQTT-Powered Inter Factory SCADA Alarm Data Analysis on Azure

SCADA engineers would like to create and store alarms across different factories in a centralized location that they can retrieve and perform analysis on. They can create these alarms using Azure Data Explorer using data stored on Azure Storage and then retrieve it as needed. For this to happen, the Factory SCADA Alarm data could flow through the HiveMQ Broker on cloud to Azure where it can be ingested using Azure Event Hubs, stored on Azure Storage and analyzed using Azure Data Explorer. Below is the architecture for the same.

There are two major advantages to using a HiveMQ broker in this scenario. First is that it provides a very scalable solution with load balancers to balance the load of the data flowing in from different factory SCADA systems that could be in different regions of the world. Second is that it offers tools to provide the high level of factory IoT data observability required to ensure that there is transparency in case there are any bottlenecks coming into the factory or at the cloud level.

Efficient Factory Command and Control With MQTT and Azure

Automation engineers in charge of industrial automation of Power gen machines in one of the factories would like to bring in some external data like weather data and other information to make a decision on how to optimally operate the machine. They can use serverless azure functions on the Azure cloud to create and run custom logic that cannot be run on the programmable logic controller (PLC). This serverless function collects information like weather data or other relevant 3rd party events through web hooks and sends that back to the PLC. This can then be used to control the machine. This can be done in multiple ways on Azure. One way is to have a web visualization application tied to a Serverless Azure Function sending data through the Azure Event Hubs to the HiveMQ Broker which can then send the data to the Power Gen Factory PLC. If the PLC wants to communicate to the cloud, it can send the data to the HiveMQ Broker on Cloud which then sends the data through the Azure Event Hubs to the Serverless Azure Function from where it can be visualized on the Web Visualization application. Here is the architecture for these options.

There are two major advantages to using a HiveMQ broker in this scenario. First is that it provides a very secure connection between the Azure serverless function and the factory machine that it is being controlled through the PLC as the machine cannot be compromised. Second is that it offers tools to provide the high level of factory IoT data observability required to ensure that there is transparency in case there are any bottlenecks coming into the factory or at the cloud level.

Manufacturing Reference Architectures for Cold Path Use Cases

Using MQTT for Long-term Factory Data Analytics on Azure

Data Scientists and data engineers want to perform less time critical and asynchronous Artificial Intelligence (AI) / Machine Learning (ML) based analytics on the data coming from the factory machines and process systems. They can hook on cloud analytics tools on top of the Azure Data Lake to perform analytics and use tools like Power BI or Grafana to visualize. This can be done by having the Factory data (various different kinds of data) talk to the HiveMQ Broker on Cloud which then sends it through the Azure Event Hubs to the Azure Data Lake from where the analytics could be done through tools like Databricks, Hadoop or Azure Data Explorer. Here is the architecture for this use case.

There are two major advantages to using a HiveMQ broker in this scenario. First is that it provides a very highly reliable and scalable connection between the data sitting in the various factory systems across the world and the Azure cloud to ensure that data is available for long term analytics and visualization. Second is that tools to provide the high level of factory IoT data observability required ensure that there is transparency in case there are any bottlenecks coming into the factory or at the cloud level.

There could be other ways to perform some of these use cases like for example the HiveMQ Kafka extension could be used to send the data to a Kafka cluster which can then hook on to other applications to perform these use cases.