Architettura OPC UA: Modello informativo, sicurezza, sessioni e trasporto

Struttura dello standard IEC 62541

IEC 62541 è composta da 13 parti numerate. Le parti 1–7 definiscono l'architettura principale; le parti 8–14 coprono mapping, sicurezza e profili. Per gli integratori di automazione degli edifici, le parti più rilevanti sono 1 (Concetti), 3 (Modello dello spazio degli indirizzi), 4 (Servizi), 6 (Mapping — codifica e trasporto), 7 (Profili) e la specifica complementare IEC 62541-100 (OPC UA per edifici).

Modello informativo: tipi NodeClass e riferimenti

Ogni dato in un server OPC UA è rappresentato come un nodo nello spazio degli indirizzi. I nodi hanno un attributo NodeClass che ne definisce il ruolo. I nodi sono collegati tra loro da riferimenti tipizzati – ad esempio, HasComponent, HasProperty, Organizes, HasSubtype. Questo crea un grafo orientato che i client possono esplorare per scoprire il contenuto del server senza conoscere preventivamente la struttura dei dati.

Spazio degli indirizzi: namespace e albero navigabile

Lo spazio degli indirizzi è strutturato come un albero navigabile. Ogni nodo è identificato da un NodeId composto da un indice di namespace e un identificatore (numerico, stringa o GUID). Il namespace 0 (ns=0) è sempre il namespace standard OPC UA contenente i tipi incorporati e i nodi standard. I namespace 1+ sono assegnati dal server per contenuti specifici del fornitore o dell'applicazione. I client scoprono la tabella dei namespace tramite la chiamata al servizio GetNamespaceArray.

Objects (ns=0;i=85)  ← OPC UA standard root
├── Server (ns=0;i=2253)  ← always present, server diagnostics
└── Building_01 (ns=1;s=Building_01)  ← application namespace
    ├── Floor_02 (ns=1;s=Building_01/Floor_02)
    │   ├── AHU_01 (ns=1;s=AHU_01)  [Object]
    │   │   ├── SupplyAirTemperature (ns=1;s=AHU_01.SAT)  [Variable, Float]
    │   │   │   ├── EngineeringUnits  [Property: "°C"]
    │   │   │   ├── EURange  [Property: Low=0, High=60]
    │   │   │   └── StatusCode  [Property: Good/Bad/Uncertain]
    │   │   ├── FanSpeed (ns=1;s=AHU_01.FanRPM)  [Variable, UInt16]
    │   │   ├── DamperPosition (ns=1;s=AHU_01.Damper)  [Variable, Byte, 0–100%]
    │   │   └── ResetAlarm (ns=1;s=AHU_01.ResetAlarm)  [Method]
    │   └── VAV_Zone_2A (ns=1;s=VAV_2A)  [Object]
    │       ├── RoomTemperature (ns=1;s=VAV_2A.RoomTemp)  [Variable, Float]
    │       └── Setpoint (ns=1;s=VAV_2A.SP)  [Variable, Float, writable]
    └── Meters (ns=1;s=Meters)
        └── Main_kWh (ns=1;s=Meter.kWh)  [Variable, Double]

I client navigano dalla radice Objects utilizzando il servizio Browse, seguendo i riferimenti gerarchici (HasComponent, Organizes, HasProperty) per scoprire i nodi. Il servizio TranslateBrowsePathsToNodeIds consente ai client di saltare direttamente a un percorso noto senza attraversare l'intero albero — utile per il polling sensibile alle prestazioni di variabili note.

Opzioni di trasporto

OPC UA definisce tre binding di trasporto. La scelta influisce su latenza, attraversamento firewall e overhead del protocollo. OPC UA Binary su TCP è il default per l'integrazione BMS a livello di impianto; HTTPS e WebSocket sono utilizzati per interfacce cloud o accessibili dal browser.

Modalità di sicurezza e politiche di sicurezza

La sicurezza OPC UA viene negoziata a livello di Secure Channel prima dello scambio di messaggi applicativi. Il server pubblica i suoi EndpointDescriptions supportati (combinazioni di MessageSecurityMode e SecurityPolicyUri). Il client ne seleziona uno all'apertura di una connessione. Non utilizzare mai None in un ambiente di produzione – trasmette tutti i dati in chiaro senza protezione dell'integrità.

SecurityPolicyUri seleziona gli algoritmi crittografici. Le politiche attualmente raccomandate (secondo IEC 62541-7:2022) sono:

Metodi di autenticazione

L'autenticazione viene eseguita a livello di sessione (sopra il canale sicuro). OPC UA definisce tre tipi di token di identità ActivateSession. L'autenticazione basata su certificato è la più sicura ed è richiesta per gli standard di sicurezza industriale come IEC 62443-3-3 Security Level 2.

Sessioni e sottoscrizioni

Una sessione viene stabilita sul canale sicuro dopo l'autenticazione. Le sessioni hanno un RequestedSessionTimeout (tipicamente 60–3600 secondi); se il client non invia un keep-alive prima della scadenza, il server elimina la sessione e tutte le sue sottoscrizioni. I client dovrebbero gestire la riconnessione con ripristino o trasferimento della sessione.

Le sottoscrizioni sono il meccanismo principale per il monitoraggio efficiente dei dati. Invece di interrogare ripetutamente le variabili (che genera traffico inutile), i client creano una sottoscrizione con un PublishingInterval e aggiungono MonitoredItems. Il server campiona ogni MonitoredItem all'intervallo SamplingInterval e accoda le modifiche dei valori; quando scatta il PublishingInterval, tutte le notifiche in coda vengono inviate in un unico messaggio PublishResponse.

CreateSubscription request:
  RequestedPublishingInterval: 1000  // ms — how often server sends Publish
  RequestedMaxKeepAliveCount: 10     // Publish cycles before keep-alive sent
  RequestedLifetimeCount: 30         // LifetimeCount × PublishingInterval = session timeout
  MaxNotificationsPerPublish: 1000   // cap notifications per PublishResponse
  PublishingEnabled: true

MonitoredItem parameters:
  SamplingInterval: 500              // ms — server samples item at this rate
                                     // must be ≥ server MinSupportedSampleRate
  QueueSize: 10                      // buffer for overrun; 1 = last value only
  DiscardOldest: true                // discard oldest on queue overflow
  DeadbandType: None / Absolute / Percent
  DeadbandValue: 0.5                 // Absolute: only report if change > 0.5 units
                                     // Percent: only report if change > 0.5% of EURange

Specifiche companion OPC UA

Le specifiche companion estendono lo standard base OPC UA con modelli informativi specifici del dominio. Definiscono ObjectTypes, VariableTypes e URI di namespace standard in modo che dispositivi di diversi produttori espongano i dati in una struttura coerente e interoperabile. Gli ingegneri di automazione degli edifici dovrebbero conoscere le seguenti specifiche companion: