Architecture OPC UA : Modèle d'information, sécurité, sessions et transport

Structure de la norme IEC 62541

IEC 62541 se compose de 13 parties numérotées. Les parties 1 à 7 définissent l'architecture de base ; les parties 8 à 14 couvrent les mappages, la sécurité et les profils. Pour les intégrateurs d'automatisation des bâtiments, les parties les plus pertinentes sont 1 (Concepts), 3 (Modèle d'espace d'adressage), 4 (Services), 6 (Mappages — codage et transport), 7 (Profils) et la spécification compagnon IEC 62541-100 (OPC UA pour les bâtiments).

Modèle d'information : types NodeClass et références

Chaque donnée dans un serveur OPC UA est représentée comme un nœud dans l'espace d'adressage. Les nœuds ont un attribut NodeClass qui définit leur rôle. Les nœuds sont liés entre eux par des références typées – par exemple, HasComponent, HasProperty, Organizes, HasSubtype. Cela crée un graphe orienté que les clients peuvent parcourir pour découvrir le contenu du serveur sans connaissance préalable de la structure des données.

Espace d'adressage : espaces de noms et arbre navigable

L'espace d'adressage est structuré comme un arbre navigable. Chaque nœud est identifié par un NodeId composé d'un index d'espace de noms et d'un identifiant (numérique, chaîne ou GUID). L'espace de noms 0 (ns=0) est toujours l'espace de noms standard OPC UA contenant les types intégrés et les nœuds standard. Les espaces de noms 1+ sont attribués par le serveur pour le contenu spécifique au fournisseur ou à l'application. Les clients découvrent la table des espaces de noms via l'appel de service 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]

Les clients naviguent à partir de la racine Objects en utilisant le service Browse, en suivant les références hiérarchiques (HasComponent, Organizes, HasProperty) pour découvrir les nœuds. Le service TranslateBrowsePathsToNodeIds permet aux clients d'accéder directement à un chemin connu sans parcourir tout l'arbre — utile pour l'interrogation sensible aux performances de variables connues.

Options de transport

OPC UA définit trois liaisons de transport. Le choix affecte la latence, le passage à travers les pare-feux et la surcharge du protocole. OPC UA Binary sur TCP est la valeur par défaut pour l'intégration BMS au niveau de l'usine ; HTTPS et WebSockets sont utilisés pour les interfaces cloud ou accessibles par navigateur.

Modes de sécurité et politiques de sécurité

La sécurité OPC UA est négociée au niveau du canal sécurisé avant tout échange de messages d'application. Le serveur annonce ses EndpointDescriptions supportées (combinaisons de MessageSecurityMode et SecurityPolicyUri). Le client en sélectionne une lors de l'ouverture d'une connexion. N'utilisez jamais None dans un environnement de production – il transmet toutes les données en clair sans protection d'intégrité.

La SecurityPolicyUri sélectionne les algorithmes cryptographiques. Les politiques actuellement recommandées (selon IEC 62541-7:2022) sont :

Méthodes d'authentification

L'authentification est effectuée au niveau de la session (au-dessus du canal sécurisé). OPC UA définit trois types de jetons d'identité ActivateSession. L'authentification par certificat est la plus sécurisée et est requise pour les normes de sécurité industrielle telles que IEC 62443-3-3 Security Level 2.

Sessions et abonnements

Une session est établie sur le canal sécurisé après authentification. Les sessions ont un RequestedSessionTimeout (généralement 60 à 3600 secondes) ; si le client n'envoie pas de keep-alive avant l'expiration, le serveur supprime la session et tous ses abonnements. Les clients doivent gérer la reconnexion avec rétablissement ou transfert de session.

Les abonnements sont le mécanisme principal pour une surveillance efficace des données. Au lieu d'interroger les variables à plusieurs reprises (ce qui génère un trafic inutile), les clients créent un abonnement avec un PublishingInterval et y ajoutent des MonitoredItems. Le serveur échantillonne chaque MonitoredItem à l'intervalle SamplingInterval et met en file d'attente les changements de valeur ; lorsque le PublishingInterval se déclenche, toutes les notifications en attente sont envoyées dans un seul message 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

Spécifications compagnons OPC UA

Les spécifications compagnons étendent le standard de base OPC UA avec des modèles d'information spécifiques au domaine. Elles définissent des ObjectTypes, VariableTypes et URI d'espace de noms standard afin que les appareils de différents fabricants exposent les données dans une structure cohérente et interopérable. Les ingénieurs en automatisation des bâtiments doivent connaître les spécifications compagnons suivantes :