In an Operational Technology (OT) environment with PLCs, SCADA systems, sensors, and actuators, Azure IoT can help bridge the gap between these devices and the cloud for data collection, monitoring, and control. Here’s a breakdown of the key components:
Azure IoT:
Azure IoT is Microsoft’s suite of cloud services tailored for connecting, managing, and analyzing data from IoT devices in various industries. It is one of the cloud market leader as declared by Gartner:
Azure IoT Hub:
Acts as the central cloud service in Azure IoT. It’s the message broker where your OT devices send their data and receive commands (if applicable). Think of it as a central message station for your devices. It is a managed service within Azure IoT for bidirectional communication between IoT devices and cloud applications. It handles device-to-cloud (D2C) and cloud-to-device (C2D) messaging, device management, and security at scale.
Choosing a Communication Protocol:
| Communication Protocol | Description | General Application Device |
| MQTT (on TCP port 8883) | i- Publish/subscribe messaging protocol for lightweight devices. ii- Devices publish telemetry data to topics. iii- Azure IoT Hub subscribes to the topics and receives data. | Battery-powered devices with small data packets. Use on all devices that don’t require connection to multiple devices, each with its own per-device credentials, over the same TLS connection. Its typical use case is for Basic device telemetry. |
| MQTT over WebSockets (on TCP port 443) | i- Uses MQTT protocol over a WebSocket connection. ii- Enables communication through firewalls that might block standard MQTT ports. iii- Ideal for web browsers acting as IoT devices for simulation purposes. | Low bandwidth & secure connection. Its typical use case is for Browser-based simulations. |
| AMQP (on TCP port 5671) | i- Advanced Message Queuing Protocol for more complex message exchanges. ii- Supports features like guaranteed delivery and message ordering. iii- Well-suited for field gateways managing multiple devices. | To send large amounts of data frequently and connection multiplexing across devices. Its typical use case is for Field gateways managing multiple devices. |
| AMQP over WebSockets (on TCP port 443) | i- Combines AMQP with Websockets for firewall traversal and browser compatibility. ii- Used in scenarios requiring AMQP’s features behind firewalls or with web browsers. | High data volume and connection multiplexing across devices. Its typical use case is for Complex messaging with firewalls or web browsers. |
| HTTPS (on TCP port 443) | i- Secure communication protocol for basic device-to-cloud communication. ii- Less efficient for real-time messaging due to lack of server-push for cloud-to-device messages. iii- Suitable for low-power devices with limited resources or those that connect infrequently. | Use for devices that can’t support other protocols. Its typical use case is Low-power devices & infrequent connections. |
- A combination of above communication protocols can also be integrated by leveraging Azure IoT Hub Routing Rules.
- If a field device does not support the above protocols then via a Gateway extension it could be integrated with Azure IoT Hub. Essentially, the gateway acts as an intermediary that bridges the communication gap between your devices’ custom language and the language understood by Azure IoT Hub. However, such a gateway can be created in the field nearby the device using Azure IoT Edge Module or on cloud or on-premises environment using Azure IoT Protocol Gateway.
Connecting Devices:
- Azure IoT Device SDKs: Use platform-specific SDKs (C#, Python, Java etc.) for easier device development and communication with Azure IoT Hub.
- Connection String: Secure your connection with a device connection string containing credentials.
Sending Device Messages (Device-to-Cloud):
- Telemetry Data: Devices can send sensor readings, status updates, or other data as messages to Azure IoT Hub.
- Message Properties: Optionally include metadata with messages for better organization and filtering.
Receiving Messages (Cloud-to-Device):
- Cloud-to-Device Messages: Send messages from your cloud application to specific devices or device groups for control or configuration updates.
- Direct Method Calls: Invoke methods directly on devices for real-time interaction.
How to implement MQTT broker on Microsoft Azure IoT?
Microsoft Azure IoT Hub itself functions as an MQTT broker for your devices. It provides secure, two-way communication between your IoT devices and Azure services. Here’s a breakdown of the key points:
- Using Azure IoT Hub as an MQTT Broker: Azure IoT Hub offers built-in MQTT support. You can leverage device SDKs in various languages (like Java, Node.js, C, C#, and Python) to connect your devices using MQTT protocol. The SDKs handle authentication and message exchange.
- Benefits:
- Secured communication
- Two-way messaging (device to cloud and cloud to device)
- Scalability to handle numerous devices
- Limitations:
- You cannot deploy your own MQTT broker on Azure IoT Hub infrastructure.
Azure IoT Hub Routing Rules:
The magic happens within Azure IoT Hub itself through message routing rules. These rules define how incoming messages, based on their protocol or other characteristics, are directed within Azure for further processing or storage.
- You can set up rules to:
- Route messages based on the protocol used (e.g., send MQTT messages from sensors to Azure Stream Analytics for real-time processing).
- Route messages based on device IDs or even the content of the message itself, regardless of the protocol used. This allows for more granular control.
Azure IoT Hub Routing Rules Example
Here’s an example:
- Imagine a scenario with two device types:
- Battery-powered sensors sending temperature data (MQTT)
- Gateways collecting data from multiple sensors and sending it to the cloud (AMQP)
- You can configure routing rules in Azure IoT Hub:
- Rule 1: If the message protocol is MQTT, send it to Azure Stream Analytics for real-time temperature analysis.
- Rule 2: If the message protocol is AMQP (likely from gateways), send it to Azure Blob storage for historical data collection.
Azure IoT Edge Module as a Field Gateway:
This is a dedicated hardware gateway device that sits between your devices and the cloud. So, this physical gateway translates the custom protocol (like MODBUS RTU, MODBUS TCP, etc) from your devices into a format (like MQTT or AMQP) compatible with Azure IoT Hub. These are self-contained programs deployed on or nearby the device with Azure IoT Edge Runtime. They can perform various tasks on the data locally before potentially sending it to the cloud (Azure IoT Hub). An example IoT Edge Module for MODBUS TCP is given here on GitHub.
In OT context, different edge gateway solutions are being provided by the vendors: Prosoft Technology and Anybus by HMS Networks. However, there might be a need to build a custom one. Edge computing has gained traction, allowing for real-time data processing and analysis at the edge of the network, reducing latency and enhancing efficiency.
So, Azure IoT Edge Module option extends Azure IoT capabilities to the edge, allowing data processing and analytics to be performed closer to where the data is generated. It enables real-time decision-making and reduces latency by running modules on edge devices.
- Think of IoT Edge Module like a small translator app running on a powerful device (like a gateway device) near your actual field devices.
- Your devices talk to the gateway using their custom protocols (like MODBUS RTU, MODBUS TCP, etc).
- The gateway, running IoT Edge, translates that custom language into a language Azure IoT Hub understands (like MQTT or AMQP).
- Now, the gateway can talk to Azure IoT Hub on behalf of your devices.
Azure IoT Edge Runtime:
The runtime environment for Azure IoT Edge modules, enabling deployment and execution of custom code or pre-built modules on edge devices. It manages module lifecycle, communication with IoT Hub, and security at the edge. Imagine this as a lightweight software layer installed on your industrial gateway or a powerful PLC. It enables the device to run Azure IoT Edge modules and become an “intelligent edge” device.
Azure IoT Protocol Gateway as a Cloud Gateway:
Azure IoT Protocol is cloud based and acts like a small translation app understanding field devices’ custom protocol and translating it into a language Azure IoT Hub understands (like MQTT or AMQP).
- Imagine the Azure IoT protocol gateway as a cloud-based translator.
- Your devices send messages using their custom protocol directly to the cloud.
- The Azure IoT protocol gateway acts as a middleman. It receives the message in the custom language.
- This gateway translates the message into a language Azure IoT Hub understands.
- Finally, the translated message is delivered to Azure IoT Hub.
Why Azure IoT as IIoT?
In traditional OT setups, SCADA systems work hand-in-hand with data historians to provide a comprehensive solution. But, Azure IoT can bridge the gap between your OT data and cloud-based advance analytics and machine learning tools for deeper insights. This allows you to extract deeper insights from your data, identify hidden patterns, and predict potential issues in advance. Predictive maintenance powered by IoT and machine learning has revolutionized asset management, reducing downtime and optimizing operational efficiency.
The key takeaway is that Azure IoT isn’t a direct replacement for SCADA, but rather a powerful tool that can extend its capabilities and unlock new possibilities in the realm of Industrial IoT (IIoT). Azure IoT Hub seamlessly integrates with other Azure services like Azure Stream Analytics, Azure Machine Learning, and Azure Blob storage. This allows you to analyze real-time data, build machine learning models, and store historical data for further analysis.
SCADA System:
- Think of it as the main control room monitoring and managing your PLCs, sensors, and actuators.
Azure IoT Hub:
- This is like a secure, cloud-based extension of your SCADA system, allowing access to device data and enabling remote monitoring from anywhere.
Azure IoT Edge Runtime & Modules:
- Imagine these as additional functionalities you can “plug-in” to your SCADA system (running on the industrial gateway). The modules process data locally before sending it to the cloud, offering benefits like faster response times and reduced bandwidth consumption.
By combining these components, you can create a powerful and scalable solution for:
Remote monitoring of industrial equipment:
- Get real-time insights into sensor data from PLCs and sensors for proactive maintenance and performance optimization.
Data pre-processing and analytics at the edge:
- Reduce network traffic and enable faster decision-making by processing and analyzing data closer to the source (on the industrial gateway with Azure IoT Edge modules).
Enabling remote control capabilities (if applicable):
- In specific scenarios, you might use Azure IoT Hub to send control commands to devices in the field through the Azure IoT Edge runtime.
Azure IoT Development Tools:
We list below some of the important Azure IoT tools and resource’s provided by Microsoft.
Azure IoT Documentation published by the IoT vendor, Microsoft.
Azure IoT Hub Documentation published by the IoT vendor, Microsoft.
Azure IoT Hub Extension for Visual Studio Code (VSC).
Azure IoT Edge Extension for Visual Studio Code (VSC).
Azure IoT Reference Architecture
Note: Overall, Microsoft Azure IoT helps bridge the gap between your OT environment and the IT cloud, offering improved data management, faster insights, and potentially enabling new control capabilities. You can engage our globally available OT and IT including Azure IoT freelancers by calling or contacting us 24/7. Microsoft used to be an IT vendor and now it is becoming essentially integrated with OT vendors (SIEMENS, Rockwell Automation, Schneider Electric, Ignition Automation, GE-fanuc, etc).
