Condividi tramite

Esercitazione: Aggiungere asset OPC UA al cluster Operazioni di Azure IoT

In questa esercitazione si aggiungeranno manualmente asset OPC UA al cluster Operazioni di Azure IoT. Questi asset pubblicano messaggi nel broker MQTT nel cluster Operazioni di Azure IoT. In genere, un utente OT completa questi passaggi.

Un asset è un dispositivo fisico o un'entità logica che rappresenta un dispositivo, un computer, un sistema o un processo. Ad esempio, un asset fisico può essere una pompa, un motore, un serbatoio o una linea di produzione. Un asset logico definito può avere proprietà, punti dati di flusso o generare eventi.

I server OPC UA sono applicazioni software che comunicano con gli asset. Tag OPC UA sono punti dati esposti dai server OPC UA. I tag OPC UA possono fornire dati in tempo reale o cronologici sullo stato, le prestazioni, la qualità o la condizione degli asset.

In questa esercitazione si userà l'interfaccia utente Web dell'esperienza operativa per creare gli asset. È anche possibile usare l'Interfaccia della riga di comando di Azure per completare alcune di queste attività.

Prerequisiti

Istanza di Operazioni IoT di Azure con impostazioni sicure abilitate distribuite in un cluster Kubernetes. Per creare un'istanza, usare una delle operazioni seguenti per distribuire Operazioni di Azure IoT:

Dopo aver abilitato le impostazioni di protezione, il gruppo di risorse che contiene l'istanza di Operazioni IoT di Azure contiene anche le risorse seguenti:

  • Istanza di Azure Key Vault per archiviare i segreti da sincronizzare nel cluster Kubernetes.
  • Identità gestita assegnata dall'utente usata da Azure IoT Operations per accedere all'istanza di Azure Key Vault.
  • Identità gestita assegnata dall'utente che i componenti di Operazioni IoT di Azure, ad esempio i flussi di dati, possono usare per connettersi agli endpoint cloud, ad esempio Hub eventi di Azure.

Assicurarsi che quando si configurano le impostazioni sicure si assegni all'account utente le autorizzazioni per gestire i segreti con il ruolo di Responsabile dei segreti di Key Vault.

Per accedere all'interfaccia utente web dell'esperienza operativa, è necessario un account Microsoft Entra ID con almeno le autorizzazioni di collaboratore per il gruppo di risorse che contiene l'istanza di Kubernetes - Azure Arc. Per altre informazioni, vedere Interfaccia utente Web dell'esperienza operativa.

Se non diversamente specificato, è possibile eseguire i comandi della console in questa esercitazione in un ambiente Bash o PowerShell.

Quale problema si risolverà?

I dati esposti dai server OPC UA possono avere una struttura complessa e possono essere difficili da comprendere. Le operazioni di Azure IoT consentono di modellare gli asset OPC UA come tag, eventi e proprietà. Questa modellazione semplifica la comprensione dei dati e l'uso in processi downstream, ad esempio il broker MQTT e i flussi di dati.

L'esercitazione illustra anche come usare le credenziali archiviate in Azure Key Vault per eseguire l'autenticazione al server OPC UA simulato.

Distribuire il simulatore OPC PLC

Questa esercitazione usa il simulatore OPC PLC per generare dati campione. Per distribuire il simulatore OPC PLC:

  1. Scaricare il file opc-plc-tutorial-deployment.yaml dal repository GitHub. Per scaricare usando la riga di comando, eseguire il comando seguente:

    wget https://raw.githubusercontent.com/Azure-Samples/explore-iot-operations/refs/heads/main/samples/quickstarts/opc-plc-tutorial-deployment.yaml -O opc-plc-tutorial-deployment.yaml

  2. Aprire il opc-plc-tutorial-deployment.yaml file scaricato in un editor di testo e modificare la password per il simulatore. La password viene impostata usando il --defaultpassword parametro . Prendere nota del valore della password, necessario in un secondo momento. Salvare quindi le modifiche.

  3. Per distribuire il simulatore OPC PLC nel cluster, eseguire il comando seguente:

    kubectl apply -f opc-plc-tutorial-deployment.yaml

Il frammento di codice seguente mostra il file YAML applicato:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: opc-plc-000000
  namespace: azure-iot-operations
  labels:
    app.kubernetes.io/component: opcplc-000000
spec:
  replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/component: opcplc-000000
  template:
    metadata:
      labels:
        app.kubernetes.io/component: opcplc-000000
    spec:
      containers:
      - name: opc-plc
        image: mcr.microsoft.com/iotedge/opc-plc:latest
        args:
          - "--plchostname=opcplc-000000"
          - "--portnum=50000"
          - "--certdnsnames=opcplc-000000"
          - "--unsecuretransport"
          - "--showpnjsonph"
          - "--slownodes=5"
          - "--slowrate=10"
          - "--fastnodes=10"
          - "--fasttypelowerbound=212"
          - "--fasttypeupperbound=273"
          - "--fasttyperandomization=True"
          - "--veryfastrate=1000"
          - "--guidnodes=1"
          - "--appcertstoretype=FlatDirectory"
          - "--dontrejectunknownrevocationstatus"
          - "--disableanonymousauth"
          - "--defaultuser=contosouser"
          - "--defaultpassword=contosouserpassword"
        ports:
        - containerPort: 50000
        volumeMounts:
          - name: opc-plc-default-application-cert
            mountPath: /app/pki/own
          - name: opc-plc-trust-list
            mountPath: /app/pki/trusted
      volumes:
        - name: opc-plc-default-application-cert
          secret:
            secretName: opc-plc-default-application-cert
        - name: opc-plc-trust-list
          secret:
            secretName: opc-plc-trust-list
      serviceAccountName: opcplc-000000-service-account
---
apiVersion: v1
kind: Service
metadata:
  name: opcplc-000000
  namespace: azure-iot-operations
  labels:
    app.kubernetes.io/component: opcplc-000000
spec:
  type: ClusterIP
  selector:
    app.kubernetes.io/component: opcplc-000000
  ports:
    - port: 50000
      protocol: TCP
      targetPort: 50000
---
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: opc-plc-self-signed-issuer
  namespace: azure-iot-operations
  labels:
    app.kubernetes.io/component: opcplc-000000
spec:
  selfSigned: {}
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: opc-plc-default-application-cert
  namespace: azure-iot-operations
  labels:
    app.kubernetes.io/component: opcplc-000000
spec:
  secretName: opc-plc-default-application-cert
  duration: 2160h # 90d
  renewBefore: 360h # 15d
  issuerRef:
    name: opc-plc-self-signed-issuer
    kind: Issuer
  commonName: OpcPlc
  dnsNames:
    - opcplc-000000
    - opcplc-000000.azure-iot-operations.svc.cluster.local
    - opcplc-000000.azure-iot-operations
  uris:
    - urn:OpcPlc:opcplc-000000
  usages:
    - digital signature
    - key encipherment
    - data encipherment
    - server auth
    - client auth
  privateKey:
    algorithm: RSA
    size: 2048
  encodeUsagesInRequest: true
  isCA: false
---
apiVersion: v1
kind: Secret
metadata:
  name: opc-plc-trust-list
  namespace: azure-iot-operations
  labels:
    app.kubernetes.io/component: opcplc-000000
data: {}
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: opcplc-000000-service-account
  namespace: azure-iot-operations
  labels:
    app.kubernetes.io/component: opcplc-000000
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: opc-plc-000000-secret-access-role
  namespace: azure-iot-operations
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "patch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: opc-plc-000000-secret-access-rolebinding
  namespace: azure-iot-operations
subjects:
- kind: ServiceAccount
  name: opcplc-000000-service-account
  namespace: azure-iot-operations
roleRef:
  kind: Role
  name: opc-plc-000000-secret-access-role
  apiGroup: rbac.authorization.k8s.io

Stabilire la fiducia reciproca

Prima che il simulatore OPC PLC possa inviare dati al connettore per OPC UA, è necessario stabilire un trust reciproco tra di essi. In questa esercitazione, il simulatore OPC PLC e il connettore per OPC UA usano certificati autofirmati per stabilire l'attendibilità reciproca con il connettore per OPC UA:

  • Il certificato dell'istanza dell'applicazione del simulatore viene archiviato nel segreto Kubernetes opc-plc-default-application-cert.
  • Il connettore per il certificato dell'istanza dell'applicazione OPC UA viene archiviato nel segreto Kubernetes aio-opc-opcuabroker-default-application-cert.

Importante

In un ambiente di produzione usare certificati di istanza dell'applicazione di livello aziendale per stabilire l'attendibilità reciproca. Per altre informazioni, vedere Configurare un certificato dell'istanza dell'applicazione di livello aziendale.

Aggiungere il certificato del connettore all'elenco di attendibilità del simulatore

Ogni server OPC UA ha un proprio meccanismo per la gestione dell'elenco di attendibilità. Per aggiungere il certificato del connettore all'elenco di attendibilità del simulatore, eseguire i comandi seguenti:

cert=$(kubectl -n azure-iot-operations get secret aio-opc-opcuabroker-default-application-cert -o jsonpath='{.data.tls\.crt}' | base64 -d)
data=$(kubectl create secret generic temp --from-literal=opcuabroker.crt="$cert" --dry-run=client -o jsonpath='{.data}')
kubectl patch secret opc-plc-trust-list -n azure-iot-operations -p "{\"data\": $data}"

$cert = kubectl -n azure-iot-operations get secret aio-opc-opcuabroker-default-application-cert -o jsonpath='{.data.tls\.crt}' | base64 -d
$data = kubectl create secret generic temp --from-literal=opcuabroker.crt="$cert" --dry-run=client -o jsonpath='{.data}'
kubectl patch secret opc-plc-trust-list -n azure-iot-operations -p "{""data"": $data}"

Aggiungere il certificato del simulatore all'elenco di attendibilità del connettore

Ogni tipo di server OPC UA ha un proprio meccanismo per la gestione del certificato dell'istanza dell'applicazione. Per scaricare il certificato del simulatore in un file denominato opcplc-000000.crt, eseguire il comando seguente:

kubectl -n azure-iot-operations get secret opc-plc-default-application-cert -o jsonpath='{.data.tls\.crt}' | base64 -d > opcplc-000000.crt

Per aggiungere il certificato del simulatore all'elenco di attendibilità del connettore:

  1. Passare all'interfaccia utente Web dell'esperienza operativa e accedere con le credenziali di Microsoft Entra ID.

  2. Selezionare il sito. Se si sta usando una nuova distribuzione, non sono ancora presenti siti. È possibile trovare il cluster creato in precedenza selezionando Visualizza istanze non firmate. Nell'esperienza operativa, un'istanza rappresenta un cluster in cui sono state distribuite le Operazioni di Azure IoT.

    Screenshot che mostra il nodo delle istanze non assegnate nell'esperienza operativa.

  3. Selezionare l'istanza in cui sono state distribuite le operazioni IoT di Azure:

    Screenshot dell'elenco di istanze di Operazioni IoT di Azure.

    Suggerimento

    Se non vengono visualizzate istanze, potrebbe non trovarsi nel tenant di Microsoft Entra ID corretto. È possibile modificare il tenant dal menu in alto a destra nel portale.

  4. Selezionare Endpoint asset e quindi Gestire certificati e segreti:

    Screenshot che mostra come trovare la pagina Gestisci certificati nell'esperienza operativa.

  5. Nella pagina Certificati selezionare Elenco attendibilità e quindi Aggiungi nuovo certificato:

    Screenshot che mostra come aggiungere un certificato all'elenco di attendibilità nell'esperienza operativa.

  6. Selezionare Carica certificato e scegliere il opcplc-000000.crt file scaricato in precedenza. Selezionare quindi Carica:

    Screenshot che mostra un caricamento corretto del certificato.

  7. Selezionare Applica.

Il certificato dell'istanza dell'applicazione del simulatore è ora incluso nell'elenco scopi consentiti del connettore per OPC UA.

Aggiungere un endpoint di asset

In questo passaggio si usa l'esperienza operativa per aggiungere un endpoint asset che consente di connettersi al simulatore OPC PLC. Per aggiungere un endpoint di asset:

  1. Selezionare Endpoint asset e quindi Crea endpoint asset:

    Screenshot che mostra la pagina degli endpoint dell'asset nell'esperienza operativa.

  2. Immettere le informazioni sull'endpoint seguenti:

    Campo Valore
    Nome endpoint dell’asset opc-ua-connector-0
    Server URL di OPC UA opc.tcp://opcplc-000000:50000
    Modalità di autenticazione utente Username password
    Nome segreto sincronizzato plc-credentials

In questa esercitazione si aggiungeranno nuovi segreti all'istanza di Azure Key Vault dall'interfaccia utente Web dell'esperienza operativa. I segreti vengono sincronizzati automaticamente con il cluster Kubernetes:

  1. Per aggiungere un riferimento al nome utente, selezionare Aggiungi riferimento e quindi Crea nuovo.

  2. Immettere plcusername come nome del segreto e contosouser come valore del segreto. Quindi seleziona Applica.

  3. Per aggiungere un riferimento alla password, selezionare Aggiungi riferimento e quindi Crea nuovo.

  4. Immettere plcpassword come nome segreto e la password aggiunta al file opc-plc-deployment.yaml come valore del segreto. Quindi seleziona Applica.

  5. Per salvare la definizione dell'endpoint dell'asset, selezionare Crea.

Questa configurazione distribuisce un nuovo endpoint dell’asset denominato opc-ua-connector-0 nel cluster. È possibile visualizzare l'endpoint dell'asset nel portale di Azure oppure utilizzare kubectl per visualizzare l'endpoint dell'asset nel cluster Kubernetes:

kubectl get assetendpointprofile -n azure-iot-operations

È possibile visualizzare i segreti plcusername e plcpassword nell'istanza di Azure Key Vault nel gruppo di risorse. I segreti vengono sincronizzati con il cluster Kubernetes in cui è possibile visualizzarli usando il kubectl get secret plc-credentials -n azure-iot-operations comando . È anche possibile visualizzare i segreti nell'esperienza operativa nella pagina Gestisci segreti sincronizzati .

Gestire le risorse

Dopo aver selezionato l'istanza nell'esperienza operativa, viene visualizzato l'elenco disponibile di asset nella pagina Asset. Se non sono ancora presenti asset, questo elenco è vuoto:

Screenshot dell'elenco di asset vuoti di Operazioni di Azure IoT.

Creare un asset

Per creare un asset, selezionare Crea asset. Immettere quindi le informazioni seguenti sull'asset:

Campo Valore
Endpoint dell’asset opc-ua-connector-0
Nome dell'asset thermostat
Descrizione A simulated thermostat asset
Argomento MQTT predefinito azure-iot-operations/data/thermostat

Rimuovere le proprietà personalizzate esistenti e aggiungere le proprietà personalizzate seguenti. Accertarsi di usare i nomi di proprietà esatti, poiché il modello di Power BI in una query successiva vi eseguirà query:

Nome proprietà Dettagli proprietà
lotto 102
Cliente Contoso
attrezzatura Caldaia
isSpare vero
ubicazione Seattle

Screenshot della pagina dei dettagli dell'asset di Operazioni di Azure IoT.

Selezionare Avanti per passare alla pagina Aggiungi tag.

Creare tag OPC UA

Aggiungere due tag OPC UA nella pagina Aggiungi tag. Per aggiungere ogni tag, selezionare Aggiungi tag o CSV e quindi selezionare Aggiungi tag. Immettere i dettagli del tag illustrati nella tabella seguente:

ID del nodo Nome del tag Modalità di osservabilità
ns=3; s=SpikeData temperatura Nessuno

L'ID nodo qui è specifico del simulatore OPC UA. Il nodo genera valori casuali all'interno di un intervallo specificato e presenta anche picchi intermittenti.

La Modalità Osservabilità è uno dei valori seguenti: None, Gauge, Counter, Histogram o Log.

È possibile selezionare Gestisci impostazioni predefinite per modificare l'intervallo di campionamento predefinito e le dimensioni della coda per ogni tag.

Screenshot della pagina di Azure IoT Operations per l'aggiunta di tag.

Selezionare Avanti per passare alla pagina Aggiungi eventi e quindi Avanti per passare alla pagina Revisione.

Verifica

Esaminare i dettagli dell'asset e del tag e apportare eventuali modifiche necessarie prima di selezionare Crea:

Screenshot della pagina di revisione dell'asset per la creazione di Operazioni di Azure IoT.

Questa configurazione distribuisce un nuovo asset chiamato thermostat nel cluster. È possibile visualizzare gli asset nel gruppo di risorse nel portale di Azure. È anche possibile usare kubectl per visualizzare gli asset in locale nel cluster:

kubectl get assets -n azure-iot-operations

Visualizzare le risorse nel portale di Azure

Per visualizzare l'endpoint dell'asset e l'asset creati nel portale di Azure, passare al gruppo di risorse che contiene l'istanza di Operazioni di Azure IoT. È possibile visualizzare l'asset termostato nel gruppo di risorse Operazioni di Azure IoT. Se si seleziona Mostra tipi nascosti, è anche possibile visualizzare l'endpoint dell'asset:

Screenshot del portale di Azure che mostra il gruppo di risorse Operazioni di Azure IoT, inclusi l'asset e l'endpoint dell'asset.

Il portale consente di visualizzare i dettagli dell'asset. Selezionare Visualizzazione JSON per altri dettagli:

Screenshot dei dettagli delle risorse di Operazioni IoT di Azure nel portale Azure.

Verificare che i dati vengano trasmessi

Verificare che i dati vengano trasmessi al broker MQTT usando lo strumento mosquitto_sub. In questo esempio si esegue lo strumento mosquitto_sub all'interno del cluster Kubernetes:

  1. Eseguire il comando seguente per distribuire un pod che include gli strumenti mosquitto_pub e mosquitto_sub utili per interagire con il broker MQTT nel cluster:

    kubectl apply -f https://raw.githubusercontent.com/Azure-Samples/explore-iot-operations/main/samples/quickstarts/mqtt-client.yaml

    Il frammento di codice seguente mostra il file YAML applicato:

    # Important: do not use in production environments
# Create a service account
apiVersion: v1
kind: ServiceAccount
metadata:
  name: mqtt-client
  namespace: azure-iot-operations
---
# Creates a pod with mosquitto-clients and mqttui utilities in your cluster
apiVersion: v1
kind: Pod
metadata:
  name: mqtt-client
  # The namespace must match the IoT MQ BrokerListener's namespace
  # Otherwise use the long hostname: aio-broker.azure-iot-operations.svc.cluster.local
  namespace: azure-iot-operations
spec:
  # Use the "mqtt-client" service account which comes with default deployment
  # Otherwise create it with `kubectl create serviceaccount mqtt-client -n azure-iot-operations`
  serviceAccountName: mqtt-client
  containers:
    # Install mosquitto and mqttui utilities on Alpine linux
  - image: alpine
    name: mqtt-client
    command: ["sh", "-c"]
    args: ["apk add mosquitto-clients mqttui && sleep infinity"]
    resources:
      limits:
        cpu: 500m
        memory: 200Mi
      requests:
        cpu: 100m
        memory: 100Mi
    volumeMounts:
    - name: broker-sat
      mountPath: /var/run/secrets/tokens
    - name: trust-bundle
      mountPath: /var/run/certs
  volumes:
  - name: broker-sat
    projected:
      sources:
      - serviceAccountToken:
          path: broker-sat
          audience: aio-internal # Must match audience in BrokerAuthentication
          expirationSeconds: 86400
  - name: trust-bundle
    configMap:
      name: azure-iot-operations-aio-ca-trust-bundle # Default root CA cert

    Attenzione

    Questa configurazione non è sicura. Non usare questa configurazione in un ambiente di produzione.

  2. Quando il pod mqtt-client è in esecuzione, eseguire il comando seguente per creare un ambiente shell nel pod creato:

    kubectl exec --stdin --tty mqtt-client -n azure-iot-operations -- sh

  3. Nella shell Bash nel pod mqtt-client, eseguire il comando seguente per connettersi al broker MQTT usando lo strumento mosquitto_sub sottoscritto all'argomento data/thermostat:

    mosquitto_sub --host aio-broker --port 18883 --topic "azure-iot-operations/data/#" -v --debug --cafile /var/run/certs/ca.crt -D CONNECT authentication-method 'K8S-SAT' -D CONNECT authentication-data $(cat /var/run/secrets/tokens/broker-sat)

    Questo comando continua a essere eseguito e visualizza i messaggi quando arrivano nell'argomento data/thermostat finché non si preme CTRL+C per arrestarlo. Per uscire dall'ambiente della shell, digitare exit.

Per verificare che il termostato che hai aggiunto stia pubblicando dati, controllare i messaggi nell'argomento azure-iot-operations/data.

Client $server-generated/0000aaaa-11bb-cccc-dd22-eeeeee333333 received PUBLISH (d0, q0, r0, m0, 'azure-iot-operations/data/thermostat', ... (92 bytes))
azure-iot-operations/data/thermostat {"temperature":{"SourceTimestamp":"2025-02-14T11:27:44.5030912Z","Value":48.17536741017152}}
Client $server-generated/0000aaaa-11bb-cccc-dd22-eeeeee333333 received PUBLISH (d0, q0, r0, m0, 'azure-iot-operations/data/thermostat', ... (90 bytes))
azure-iot-operations/data/thermostat {"temperature":{"SourceTimestamp":"2025-02-14T11:27:45.50333Z","Value":98.22872507286887}}
Client $server-generated/0000aaaa-11bb-cccc-dd22-eeeeee333333 received PUBLISH (d0, q0, r0, m0, 'azure-iot-operations/data/thermostat', ... (92 bytes))
azure-iot-operations/data/thermostat {"temperature":{"SourceTimestamp":"2025-02-14T11:27:46.503381Z","Value":12.533323356430426}}

Se non è presente alcun flusso di dati, riavviare il pod aio-opc-opc.tcp-1:

  1. Trovare il nome del pod aio-opc-opc.tcp-1 usando il comando seguente:

    kubectl get pods -n azure-iot-operations

    Il nome del pod è simile a aio-opc-opc.tcp-1-849dd78866-vhmz6.

  2. Riavviare il pod aio-opc-opc.tcp-1 usando un comando simile all'esempio seguente. Usare il nome del pod aio-opc-opc.tcp-1 del passaggio precedente:

    kubectl delete pod aio-opc-opc.tcp-1-849dd78866-vhmz6 -n azure-iot-operations

I tag di esempio aggiunti nell'esercitazione precedente generano messaggi dall'asset simili all'esempio seguente:

{
    "temperature":{
        "Value":24.86898871648548,
        "SourceTimestamp":"2025-04-25T14:50:07.195274Z"
    }
}

Come è stato risolto il problema?

In questa esercitazione è stato aggiunto un endpoint di asset e quindi sono stati definiti un asset e tag. Gli asset e i tag modellano i dati del server OPC UA per semplificare l'uso dei dati in un broker MQTT e in altri processi downstream.

Sono state usate le credenziali archiviate in Azure Key Vault per l'autenticazione nel server OPC UA. Questo approccio è più sicuro rispetto all'inserimento fisso di credenziali nella definizione delle risorse.

L'asset termostato definito verrà usato nell'esercitazione successiva.

Pulire le risorse

Se si prosegue all'esercitazione successiva, mantenere tutte le risorse.

Se si vuole rimuovere la distribuzione di Operazioni di Azure IoT ma mantenere il cluster, usare il comando az iot ops delete:

az iot ops delete --cluster $CLUSTER_NAME --resource-group $RESOURCE_GROUP

Per eliminare tutte le risorse create per questo avvio rapido, eliminare il cluster Kubernetes in cui è stato distribuito Operazioni di Azure IoT e quindi rimuovere il gruppo di risorse di Azure che conteneva il cluster.

Se per questi argomenti della guida introduttiva è stato usato Codespaces, eliminare Codespace da GitHub.

Passaggio successivo

Esercitazione: Inviare messaggi dall'asset al cloud usando un flusso di dati.