OPC UA Architektur: Informationsmodell, Sicherheit, Sessions und Transport

IEC 62541 Standardstruktur

IEC 62541 besteht aus 13 nummerierten Teilen. Die Teile 1–7 definieren die Kernarchitektur; die Teile 8–14 decken Mappings, Sicherheit und Profile ab. Für Gebäudeautomationsintegratoren sind die relevantesten Teile 1 (Konzepte), 3 (Address Space Model), 4 (Dienste), 6 (Mappings – Kodierung und Transport), 7 (Profile) sowie die Begleitspezifikation IEC 62541-100 (OPC UA für Gebäude).

Informationsmodell: NodeClass-Typen und Referenzen

Jedes Datenelement in einem OPC UA-Server wird als Knoten im Adressraum dargestellt. Knoten haben ein NodeClass-Attribut, das ihre Rolle definiert. Knoten sind durch typisierte Referenzen miteinander verbunden – z. B. HasComponent, HasProperty, Organizes, HasSubtype. Dadurch entsteht ein gerichteter Graph, den Clients durchsuchen können, um Serverinhalte zu entdecken, ohne die Datenstruktur vorher zu kennen.

Adressraum: Namespaces und durchsuchbarer Baum

Der Adressraum ist als durchsuchbarer Baum strukturiert. Jeder Knoten wird durch eine NodeId identifiziert, die aus einem Namespace-Index und einem Identifier (numerisch, String oder GUID) besteht. Namespace 0 (ns=0) ist immer der OPC UA-Standard-Namespace, der integrierte Typen und Standardknoten enthält. Namespace 1+ werden vom Server für hersteller- oder anwendungsspezifische Inhalte vergeben. Clients entdecken die Namespace-Tabelle über den GetNamespaceArray-Dienstaufruf.

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]

Clients navigieren vom Objects-Stammverzeichnis aus mit dem Browse-Dienst, indem sie hierarchischen Referenzen (HasComponent, Organizes, HasProperty) folgen, um Knoten zu entdecken. Der TranslateBrowsePathsToNodeIds-Dienst ermöglicht es Clients, direkt zu einem bekannten Pfad zu springen, ohne den gesamten Baum zu durchlaufen – nützlich für leistungssensitives Pollen bekannter Variablen.

Transportoptionen

OPC UA definiert drei Transportbindungen. Die Wahl beeinflusst Latenz, Firewall-Durchlässigkeit und Protokoll-Overhead. OPC UA Binary über TCP ist der Standard für die BMS-Integration auf Feldebene; HTTPS und WebSockets werden für Cloud- oder browserzugängliche Schnittstellen verwendet.

Sicherheitsmodi und Sicherheitsrichtlinien

Die OPC UA-Sicherheit wird auf der Ebene des Secure Channel ausgehandelt, bevor Anwendungsnachrichten ausgetauscht werden. Der Server gibt seine unterstützten EndpointDescriptions (Kombinationen von MessageSecurityMode und SecurityPolicyUri) bekannt. Der Client wählt eine aus, wenn er eine Verbindung öffnet. Verwenden Sie None niemals in einer Produktionsumgebung – es überträgt alle Daten im Klartext ohne Integritätsschutz.

Die SecurityPolicyUri wählt die kryptografischen Algorithmen aus. Aktuelle empfohlene Richtlinien (Stand IEC 62541-7:2022) sind:

Authentifizierungsmethoden

Die Authentifizierung erfolgt auf der Sitzungsebene (oberhalb des sicheren Kanals). OPC UA definiert drei ActivateSession-Identitätstoken-Typen. Die zertifikatsbasierte Authentifizierung ist die sicherste und wird für industrielle Sicherheitsstandards wie IEC 62443-3-3 Security Level 2 gefordert.

Sitzungen und Abonnements

Eine Session wird nach der Authentifizierung auf dem Secure Channel aufgebaut. Sessions haben eine RequestedSessionTimeout (typischerweise 60–3600 Sekunden); sendet der Client vor Ablauf kein Keep-Alive, löscht der Server die Session und alle zugehörigen Abonnements. Clients sollten die Wiederverbindung mit Session-Wiederherstellung oder -Übertragung handhaben.

Abonnements sind der primäre Mechanismus für effizientes Datenmonitoring. Anstatt Variablen wiederholt abzufragen (was unnötigen Traffic erzeugt), erstellen Clients ein Abonnement mit einem PublishingInterval und fügen MonitoredItems hinzu. Der Server tastet jedes MonitoredItem im SamplingInterval ab und stellt Wertänderungen in eine Warteschlange; wenn das PublishingInterval auslöst, werden alle anstehenden Benachrichtigungen in einer einzigen PublishResponse-Nachricht gesendet.

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

OPC UA Companion Specifications

Companion Specifications erweitern den OPC-UA-Basisstandard um domänenspezifische Informationsmodelle. Sie definieren standardisierte ObjectTypes, VariableTypes und Namespace-URIs, sodass Geräte verschiedener Hersteller Daten in einer konsistenten, interoperablen Struktur bereitstellen. Gebäudeautomationsingenieure sollten die folgenden Companion Specifications kennen: