Industrial IoT connectivity patterns

IoT Edge
IoT Hub
Data Explorer

An end-to-end connectivity solution makes your organization more resilient by helping to securely connect people, assets, workflow, and business processes. The key aspects around connectivity include:

  • Devices like PLCs, sensors, equipment, and assembly lines.
  • Systems like process historian, supervisory control and data acquisition (SCADA), manufacturing execution systems (MES), and industrial control systems/distributed control systems (ICS/DCS).
  • Standards and data models like ISA 95, ISA 99, OPC Data Access (DA), OPC Unified Architecture (UA), and Modbus.
  • Network and security like:
    • Purdue model, firewalls, proxies, network inspection, 5G, and long-range WAN (LoRaWAN®).
    • X.509 certificates and access policies.
  • Edge gateways like:
    • Software only or a hardware and software solution.
    • Modular design, cloud based management plane, and offline support.
    • Layered edge processing, analytics, and machine learning.
  • Cloud gateways like cloud connectivity, transport protocols, and device management and scale.

The following sections include common connectivity patterns for industrial solutions.

Note

These patterns are for telemetry egress only. No control commands are sent back to the industrial systems or devices. These patterns are also focused on Connected operations scenarios. Connected products scenarios will be added later.

Download a PowerPoint file for the following patterns.

LoRaWAN® is a registered trademark of the LoRa Alliance® in the United States and/or other countries. No endorsement by LoRa Alliance® is implied by the use of these marks.

OPC UA server and an IoT Edge gateway

Connect to manufacturing machines by using OPC UA standards and an Azure IoT Edge gateway.

Diagram that shows how to connect machines by using an OPC UA server and an IoT Edge gateway.

Download a PowerPoint file of this pattern.

Dataflow

  1. Programmable logic controllers (PLCs) are connected to industrial connectivity software or historian software by using a switch or internal network connectivity.
  2. The OPC UA module connects to the OPC UA endpoint that's provided by the industrial connectivity software and sends the data to the edgeHub module.
  3. The edgeHub module sends the data to Azure IoT Hub or Azure IoT Central by using advanced message queuing protocol (AMQP) or MQTT.
  4. IoT Hub or Azure IoT Central uses data connection or data export to send data to Azure Data Explorer.

Potential use cases

  • Use this pattern when:
    • You've already configured an OPC UA server or can configure it to connect with PLCs.
    • You can install IoT Edge at layer 3 and connect to the PLC via an OPC UA server.

Considerations

Deploy this scenario

Protocol translation and an IoT Edge gateway

Connect to manufacturing machines over non-standard protocols by using an IoT Edge gateway.

Diagram that shows machines connected by using a custom protocol translation module and an IoT Edge gateway.

Download a PowerPoint file of this pattern.

Dataflow

  1. Devices that don't support OPC UA are connected via a custom protocol translation module to the edgeHub module.
  2. The edgeHub module sends the data to IoT Hub or Azure IoT Central by using AMQP or MQTT.
  3. IoT Hub or Azure IoT Central uses data connection or data export to send data to Azure Data Explorer.

Potential use cases

  • Use this pattern when:
    • Your devices can't support an OPC UA data model.
    • You can install IoT Edge at layer 3 and connect to your devices.

Considerations

Deploy this scenario

Cloud connector from industrial connectivity software or a historian

Connect to manufacturing machines by using a cloud connector component that's available in industrial connectivity software.

Diagram that shows machines connected by using built-in cloud connectors from historian software.

Download a PowerPoint file of this pattern.

Dataflow

  1. PLCs are connected to industrial connectivity software or historian software by using a switch or internal network connectivity.
  2. The industrial connectivity software uses AMQP or MQTT to send the data over a built-in cloud connector to IoT Hub or Azure IoT Central.
  3. IoT Hub or Azure IoT Central uses data connection or data export to send data to Azure Data Explorer.

Potential use cases

  • Use this pattern when:
    • Industrial connectivity software or historian software is available and has a built-in cloud connector.
    • You don't require management, processing, and analytics functionality for the use case.
    • The connector can provide the data with the same granularity as an edge gateway.

Considerations

Deploy this scenario

Resources

Connect to layer 2 and IoT Edge gateways

Connect to manufacturing machines in layer 2 of a Purdue model by using multiple IoT Edge gateways that are connected in a hierarchy.

Diagram that shows machines connected in layer 2 of a Purdue model by using hierarchical edge gateways.

Download a PowerPoint file of this pattern.

Dataflow

  1. PLCs are connected to the layer 2 edge gateway, which is the lower layer edge gateway.
  2. The layer 2 edge gateway sends the data to the layer 3 gateway, which is the parent device. The layer 3 gateway also has a local Docker registry and an API proxy module to support module deployment for the lower layer edge gateways.
  3. The layer 3 edgeHub module sends the data to IoT Hub or Azure IoT Central by using AMQP or MQTT.
  4. IoT Hub or Azure IoT Central uses data connection or data export to send data to Azure Data Explorer.

Potential use cases

  • Use this pattern when:
    • Layer 0~1 can only connect with the adjacent layer 2, in accordance with the ISA95 and Purdue models.
    • You can install IoT Edge at layer 2 and connect to layer 0~1.

Considerations

Deploy this scenario

Resilient edge gateway

Provide hardware resiliency for your IoT Edge gateway VMs.

Diagram that shows how to use a pattern that makes edge gateways resilient to hardware failures by using Kubernetes.

Download a PowerPoint file of this pattern.

Dataflow

  1. PLCs are connected to industrial connectivity software or historian software by using a switch or internal network connectivity.
  2. The industrial connectivity software provides an OPC UA endpoint that you connect to the OPC UA module and the OPC UA endpoint. Then, the OPC UA module sends the data to the edgeHub module. The edge runtime runs on a VM that runs inside a Kubernetes cluster.
  3. The edgeHub module sends the data to IoT Hub or Azure IoT Central by using AMQP or MQTT.
  4. IoT Hub or Azure IoT Central uses data connection or data export to send data to Azure Data Explorer.

Potential use cases

  • Use this pattern when:
    • A Kubernetes infrastructure and skill set is already available.

    • Horizontal scaling and hardware failure resiliency is critical.

    • IoT Edge VM snapshots aren't enough to meet the recovery time objective (RTO) and recovery point objective (RPO) needs.

      Note

      RTO is the maximum time an application is unavailable after an incident, and RPO is the maximum duration of data loss during a disaster.

Considerations

Deploy this scenario

Scale to multiple factories and business units

Scale connectivity patterns to multiple factories and business units.

Diagram that shows how to scale machine connectivity patterns to multiple factories.

Download a PowerPoint file of this pattern.

Dataflow

  1. Multiple factories send the data to IoT Hub or Azure IoT Central.
  2. IoT Hub or Azure IoT Central uses routes, consumer groups, and data export to push the data to multiple business units and project specific resource groups.

Potential use cases

  • Use this pattern when:
    • You need to scale industrial IoT solution patterns across multiple factories.
    • Multiple business units and projects need access to Industrial Internet of Things (IIoT) data.
    • You enable landing zone cloud connectivity.
    • You need granular access control between operational technology (OT) and IT.

Considerations

  • This pattern is for scaling cloud gateways and services, and for connecting multiple factories. It's agnostic of data models, protocols, and industrial connectivity software.
  • A dedicated subscription for a cloud gateway enables OT and networking teams to better manage cloud egress and connectivity.
  • A device provisioning service can help scale across multiple IoT Hubs and Azure IoT Central. Both of these services can use the underlying device provisioning service to provide an auto-scaling experience.
  • For scenarios where a hierarchy of edge gateways is needed, use IoT Hub directly.
  • You can push IIoT data to each business unit or project-specific subscription via routes and consumer groups.
  • IIoT solutions are one of many enterprise solutions, and must integrate well with the overall cloud operating model and landing zone design principles of your enterprise.
  • IoT Hub high availability and disaster recovery

Constrained devices and add-on sensors

Connect low-power and low-compute devices to manufacturing machines as extra sensors.

Diagram that shows how to connect machines by using a cloud S D K and custom application.

Download a PowerPoint file of this pattern.

Dataflow

  1. Constrained devices or add-on sensors send data to a custom application. You can use embedded code inside the sensor itself as the custom application.
  2. The custom application sends the data to IoT Hub or Azure IoT Central by using AMQP, MQTT, or HTTPS.
  3. IoT Hub or Azure IoT Central uses data connection or data export to send data to Azure Data Explorer.

Potential use cases

  • Use this pattern when:
    • You work with constrained devices or add-on sensors in remote and off-site locations.
    • You don't require management, processing, and analytics functionality of an edge gateway for the use case.
    • You can allow data egress to go outside of the Purdue model.

Considerations

  • This pattern requires significant deployment and management of the custom application for sensor data collection.
  • There's no support for offline or edge analytics scenarios.
  • Azure security baseline for IoT Hub.
  • To learn when to use IoT Hub instead of Azure IoT Central, see the Cloud gateway options.

Resources

Cloud gateway options

Select a cloud gateway for connectivity.

IoT Hub

Diagram that shows how to connect to a cloud gateway by using IoT Hub.

Download a PowerPoint file of this pattern.

Dataflow

  1. The edge gateway sends data to an IoT Hub by using AMQP or MQTT.
  2. Azure Data Explorer pulls the data from IoT Hub by using streaming ingestion.

Azure IoT Central

Diagram that shows how to connect to a cloud gateway by using Azure IoT Central.

Download a PowerPoint file of this pattern.

Dataflow

  1. The edge gateway sends data to Azure IoT Central by using AMQP or MQTT.
  2. Azure IoT Central exports the data to Azure Data Explorer by using data export.

Azure Event Hubs

Diagram that shows how to connect to a cloud gateway by using Event Hubs.

Download a PowerPoint file of this pattern.

Dataflow

  1. A custom application sends event hub messages by using a language-specific SDK.
  2. Azure Data Explorer pulls the data from Event Hubs by using streaming ingestion.

Potential use cases

  • Use this pattern when:
    • Use IoT Hub or Azure IoT Central when you require device and edge management, two way communication, and messaging.
    • Use Azure IoT Central if you need a built-in dashboard and rules engine for alerts.
    • Use Event Hubs when you have cost constraints and only require messaging.

Considerations

Deploy this scenario

Contributors

This article is maintained by Microsoft. It was originally written by the following contributors.

Principal author:

Other contributor:

To see non-public LinkedIn profiles, sign in to LinkedIn.

Next steps