Note
This article is the Microsoft OPC UA reference solution, which uses IEC 62541 standard OPC UA PubSub to send telemetry data from the edge to the cloud. It is different from other telemetry configurations of Azure IoT Operations, since Azure IoT Operations also caters for scenarions where no OPC UA-enabled telemetry sources are involved, i.e. OPC UA PubSub is not required between Azure IoT Operations and cloud endpoints. The Azure IoT Operations architecture is described in the Azure IoT Operations Overview.
Manufacturers want to use an industrial IoT solution that doesn't lock them in to walled-garden ecosystems. In addition, they want to deploy this solution on a global scale and connect all of their production sites to it to increase efficiencies for each individual site.
These increased efficiencies lead to faster production, better quality and lower energy consumption, which all lead to lowering the cost for the produced goods.
The solution must be as efficient as possible and enable all required use cases such as condition monitoring, overall equipment effectiveness (OEE) calculation, forecasting, and anomaly detection. By using the insights gained from these use cases, manufacturers can then create digital feedback loops, which can apply optimizations and other changes to the production processes fully automatically.
Interoperability is the key enabler for these requirements. The use of open standards such as OPC UA significantly helps to achieve this interoperability, which lead to the establishment of the OPC Foundation Cloud Initiative. This OPC UA reference solution is Microsoft's implementation of the Cloud Initiative's reference architecture.
This reference solution deploys Azure Arc, which requires the custom-locations application object ID that needs to be passed to the deployment script. You can retrieve it with the following Azure CLI commands:
az login --tenant <tenant_id>
az account set --subscription <subscription_id>
az ad sp show --id bc313c14-388c-4e7d-a58e-70017303ee3b --query id -o tsv
The reference solution also deploys Azure IoT Operations, which requires the following resource providers to be registered in the subscription. Registering a resource provider is a subscription-scope action, so it must be done once by a subscription Owner or Contributor before deployment:
az provider register --namespace Microsoft.ExtendedLocation
az provider register --namespace Microsoft.Kubernetes
az provider register --namespace Microsoft.KubernetesConfiguration
az provider register --namespace Microsoft.IoTOperations
az provider register --namespace Microsoft.DeviceRegistry
az provider register --namespace Microsoft.SecretSyncController
The reference solution also deploys the Azure IoT Schema Registry, which requires the IoT Operations Arc extension service principal to be granted the Azure Device Registry Administrator role. A subscription Owner or User Access Administrator must create this role assignment by running the following after the deployment completes. Replace <subscription_id> and <resource_group> with your values and <resources_name> with the resourcesName deployment parameter in lowercase:
az role assignment create --assignee a2127957-50f2-44e9-8434-4fed4109fc30 --role "Azure Device Registry Administrator" --scope /subscriptions/<subscription_id>/resourceGroups/<resource_group>/providers/Microsoft.DeviceRegistry/schemaRegistries/<resources_name>-schemaregistry
The following articles describe how to deploy this reference solution as well as how to connect it to various Microsoft services:
- Connect Azure Data Explorer to the reference solution describes the end-to-end industrial IoT reference solution that uses Azure Data Explorer to store and analyze OPC UA telemetry for use cases such as condition monitoring, OEE calculation, and anomaly detection.
- Connect Azure Databricks to the reference solution walks through storing and analyzing OPC UA PubSub telemetry in Azure Databricks using Delta Lake tables and Structured Streaming ingestion from Azure Event Hubs.
- Connect Microsoft Fabric to the reference solution explains how to ingest and process the reference solution's OPC UA PubSub data in a Microsoft Fabric Eventhouse for Real-Time Intelligence, mirroring the same tables, functions, and views used by Azure Data Explorer.
- Connect Microsoft Power BI to the reference solution describes how to connect Microsoft Power BI to the reference solution's OPC UA PubSub data.
- Connect Azure Managed Grafana to the reference solution describes how to connect Azure Managed Grafana to the reference solution's OPC UA PubSub data.
- Connect Microsoft Dynamics 365 Field Service to the reference solution describes how to connect Microsoft Dynamics 365 Field Service to the reference solution's OPC UA PubSub data.
- Connect SAP to the reference solution describes how to connect SAP to the reference solution.
- Connect an industrial data space to the reference solution describes how to connect an industrial data space to the reference solution.
- Import OPC UA Information Models from the UA Cloud Library into Azure services describes how to import standardized OPC UA information models from the OPC Foundation's UA Cloud Library into Azure services.
The production line simulation is made up of several stations, using the station OPC UA information model, and a simple manufacturing execution system (MES). Both the stations and the MES are containerized for easy deployment. Their configuration is:
| Production Line | Ideal Cycle Time (in seconds) |
|---|---|
| Munich | 6 |
| Seattle | 10 |
| Shift Name | Start | End |
|---|---|---|
| Morning | 07:00 | 14:00 |
| Afternoon | 15:00 | 22:00 |
| Night | 23:00 | 06:00 |
Shift times are in local time zone of Seattle and Munich. There are 1 hour breaks between shifts.
The station OPC UA server uses the following OPC UA node IDs for telemetry to the cloud:
i=379- manufactured product serial numberi=385- number of manufactured productsi=391- number of discarded productsi=398- running timei=399- faulty timei=400- status (0=station ready to do work, 1=work in progress, 2=work done and good part manufactured, 3=work done and scrap manufactured, 4=station in fault state)i=406- energy consumptioni=412- ideal cycle timei=418- actual cycle timei=434- pressure
The solution uses a digital feedback loop to manage the pressure in a simulated station. To implement the feedback loop, the solution triggers a command from the cloud on one of the OPC UA servers in the simulation. The trigger activates when simulated time-series pressure data reaches a certain threshold. You can see the pressure of the assembly machine in the Azure Data Explorer dashboard. The pressure is released at regular intervals for the Seattle production line. In a real-world deployment, something as critical as opening a pressure relief valve would be done on-premises. This example simply demonstrates how to achieve the digital feedback loop.
The simulation stations accept anonymous/untrusted OPC UA sessions only until a CA certificate is pushed to them via OPC UA Part 12 Server Push. After that, each station accepts a client certificate only if its issuer matches a certificate in the station's pki/issuer/certs store. Azure IoT Operation's connector for OPC UA uses a self-signed application instance certificate, so without extra configuration the stations would reject it once provisioned.
The deployment script establishes the required two-way (mutual) trust automatically, after Azure IoT Operations is installed:
-
Stations trust AIO. AIO's connector certificate is a self-signed, cert-manager-managed application instance certificate stored in the Kubernetes secret
aio-opc-opcuabroker-default-application-cert(namespaceazure-iot-operations) — you retrieve it, you don't generate it.The script copies this certificate into each station's issuer certs and trusted certs store.
-
AIO trusts the stations. The script adds all CA certificates found in the GDS Certificate Authority (CA) store to AIO's connector trust list.
AIO stores this in the
aio-opc-ua-broker-trust-listsecret.
Note
This is the automated equivalent of the mutual-trust procedure in Configure OPC UA certificates infrastructure for the connector for OPC UA.
When you browse the Kubernetes resources of the Arc-enabled cluster (or the Azure IoT Operations instance) in the Azure portal, you are prompted for a service account bearer token. Generate one by logging on to the deployed VM via SSH and then running the following commands:
# Create a service account (in the default namespace).
sudo kubectl --kubeconfig /etc/rancher/k3s/k3s.yaml create serviceaccount arc-portal-user -n default
# Grant it cluster-admin so it can view all resources.
sudo kubectl --kubeconfig /etc/rancher/k3s/k3s.yaml create clusterrolebinding arc-portal-user-binding --clusterrole cluster-admin --serviceaccount default:arc-portal-user
# Create a long-lived token secret for the service account.
sudo kubectl --kubeconfig /etc/rancher/k3s/k3s.yaml apply -f - <<EOF
apiVersion: v1
kind: Secret
metadata:
name: arc-portal-user-secret
annotations:
kubernetes.io/service-account.name: arc-portal-user
type: kubernetes.io/service-account-token
EOF
# Print the token, then paste it into the portal's "Service account bearer token" prompt.
sudo kubectl --kubeconfig /etc/rancher/k3s/k3s.yaml get secret arc-portal-user-secret -o jsonpath='{$.data.token}' | base64 -dThe manufacturing ontologies defined in this repository are described by leveraging the W3C Web of Things (WoT), which is specified here. They were generated by an open-source DTDL-WoT conversion tool available here. A comparison between DTDL and WoT and how the two specs interoperate is described here.
ISA95 / IEC 62264 is the manufacturing ontology leveraged by this solution. It is a standard and described here and here. The OPC UA Companion Specification for it is available here and here.
This work is licensed under a Creative Commons Attribution 4.0 International License.