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.
Download a PowerPoint file of this pattern.
Dataflow
- Programmable logic controllers (PLCs) are connected to industrial connectivity software or historian software by using a switch or internal network connectivity.
- 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.
- The edgeHub module sends the data to Azure IoT Hub or Azure IoT Central by using advanced message queuing protocol (AMQP) or MQTT.
- 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
- To deploy an IoT Edge solution, see Prepare to deploy your IoT Edge solution in production.
- To configure your OPC publisher, see the OPC publisher module configuration guide.
- For security considerations, see Azure security baseline for IoT Hub.
- You can install an IoT Edge runtime on a Linux or Windows virtual machine (VM) and dedicated hardware like Azure Stack Edge.
- To learn when to use IoT Hub instead of Azure IoT Central, see the Cloud gateway options.
Deploy this scenario
- Deployment samples:
Protocol translation and an IoT Edge gateway
Connect to manufacturing machines over non-standard protocols by using an IoT Edge gateway.
Download a PowerPoint file of this pattern.
Dataflow
- Devices that don't support OPC UA are connected via a custom protocol translation module to the edgeHub module.
- The edgeHub module sends the data to IoT Hub or Azure IoT Central by using AMQP or MQTT.
- 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
- To deploy an IoT Edge solution, see Prepare to deploy your IoT Edge solution in production.
- For security considerations, see Azure security baseline for IoT Hub.
- You can install IoT Edge runtime on a Linux or Windows VM and dedicated hardware like Azure Stack Edge.
- For partner solutions, eee the IoT Edge module marketplace.
- To learn when to use IoT Hub instead of Azure IoT Central, see the Cloud gateway options.
Deploy this scenario
- Deployment sample:
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.
Download a PowerPoint file of this pattern.
Dataflow
- PLCs are connected to industrial connectivity software or historian software by using a switch or internal network connectivity.
- 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.
- 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
- This method adds another cost for cloud connectors along with licensing and tag-based costing model for historians.
- For security considerations, see Azure security baseline for IoT Hub.
- To learn when to use IoT Hub instead of Azure IoT Central, see the Cloud gateway options.
Deploy this scenario
- Deployment sample:
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.
Download a PowerPoint file of this pattern.
Dataflow
- PLCs are connected to the layer 2 edge gateway, which is the lower layer edge gateway.
- 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.
- The layer 3 edgeHub module sends the data to IoT Hub or Azure IoT Central by using AMQP or MQTT.
- 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
- This configuration creates a complex deployment model and certificate configuration for security.
- To create an IoT Edge device hierarchy, see Tutorial: Create a hierarchy of IoT Edge devices.
- To deploy an IoT Edge solution, see Prepare to deploy your IoT Edge solution in production.
- For security considerations, see Azure security baseline for IoT Hub.
- To learn when to use IoT Hub instead of Azure IoT Central, see the Cloud gateway options.
Deploy this scenario
- Deployment sample:
Resilient edge gateway
Provide hardware resiliency for your IoT Edge gateway VMs.
Download a PowerPoint file of this pattern.
Dataflow
- PLCs are connected to industrial connectivity software or historian software by using a switch or internal network connectivity.
- 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.
- The edgeHub module sends the data to IoT Hub or Azure IoT Central by using AMQP or MQTT.
- 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
- This pattern is for hardware resiliency and is agnostic of data models, protocols, and industrial connectivity software.
- For Kubernetes information, see Choose a Kubernetes at the edge compute option.
- To deploy an IoT Edge solution, see Prepare to deploy your IoT Edge solution in production.
- For security considerations, see Azure security baseline for IoT Hub.
- To learn when to use IoT Hub instead of Azure IoT Central, see the Cloud gateway options.
Deploy this scenario
- Deployment sample:
Scale to multiple factories and business units
Scale connectivity patterns to multiple factories and business units.
Download a PowerPoint file of this pattern.
Dataflow
- Multiple factories send the data to IoT Hub or Azure IoT Central.
- 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.
Download a PowerPoint file of this pattern.
Dataflow
- 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.
- The custom application sends the data to IoT Hub or Azure IoT Central by using AMQP, MQTT, or HTTPS.
- 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
Download a PowerPoint file of this pattern.
Dataflow
- The edge gateway sends data to an IoT Hub by using AMQP or MQTT.
- Azure Data Explorer pulls the data from IoT Hub by using streaming ingestion.
Azure IoT Central
Download a PowerPoint file of this pattern.
Dataflow
- The edge gateway sends data to Azure IoT Central by using AMQP or MQTT.
- Azure IoT Central exports the data to Azure Data Explorer by using data export.
Azure Event Hubs
Download a PowerPoint file of this pattern.
Dataflow
- A custom application sends event hub messages by using a language-specific SDK.
- 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
- Connecting IoT Devices to Azure: IoT Hub and Event Hubs
- IoT Hub vs. Azure IoT Central
- RPO and RTO options for IoT Hub
- Learn about HA/DR for Azure IoT Central and limitations around IoT Edge devices.
- Learn about availability and Geo-disaster recovery for Event Hubs.
Deploy this scenario
- Deployment samples:
Contributors
This article is maintained by Microsoft. It was originally written by the following contributors.
Principal author:
- Jomit Vaghela | Principal Program Manager
Other contributor:
- Jason Martinez | Technical Writer
To see non-public LinkedIn profiles, sign in to LinkedIn.
Next steps
- Try the deployment sample for Connectivity with Industrial Assets using OPC UA and Edge for Linux on Windows (EFLOW).
- Try the deployment sample for Connecting OPC UA devices to IoT Central using custom modules.