2.
2 - Sécurité
La sécurité est un des points forts de OPC UA, comparé aux anciens protocoles de supervision
(Modbus par exemple). La sécurisation des communications en OPC UA s’appuie sur OpenSSL,
comme HTTPs (cf ressource [13]).
Le service de sécurisation est indépendant du fonctionnement de l’application OPC UA, ce service
de sécurisation reposant sur la Communication Stack. La Communication Stack communique via un
Secure Channel. Un Secure Channel est une connexion logique longue durée entre un client et un
serveur. Il est mis en place par un échange de certificats X.509 (client et serveur) et de clés
publiques (clé client et clé serveur) aboutissant à un échange de clés de chiffrement symétrique
permettant le chiffrement des échanges suivants, jusqu’à la fermeture du Secure Channel. Une
application OPC UA ignore tout message qui ne suit pas la politique de sécurité. Une session est
associée à un unique Secure Channel. Lors d’une connexion, le Secure Channel est d’abord ouvert,
puis la session est ensuite ouverte en utilisant ce canal sécurisé, comme cela sera présenté dans la
partie pratique un peu plus loin dans cette ressource.
Figure 4 : Sécurité (source [Link])
Pour les échanges de données via le Secure Channel, il existe 3 niveaux de sécurité :
• Aucun
• Avec chiffrement
• Avec chiffrement et authentification
2.3 - Discovery
Le service Discovery est décrit en détail dans la Partie 12.4 de la référence OPC UA. Ce service
permet aux applications OPC UA de rechercher d’autres applications. En général, ce sont les
serveurs qui proposent ce service afin que des clients s’y connectent, mais certains clients peuvent
avoir une connexion inversée.
Avant même de créer une session, le service de Discovery permet d’identifier un serveur. Cela
permet aussi d’avoir une vue d’ensemble de l’application, avec par exemple les variables qu’elle
propose. Les variables étant désignées par un nom explicite, le développeur évite ainsi les erreurs
d’adressage ou d’unité, typiques de modbus (on y désigne l’adresse de la variable et on récupère
sa valeur brute, sans unité).
4
2.4 - Espace d’adresses
Une fois que la connexion est établie et sécurisée, il est possible d’accéder à l’espace d’adresses
et de commencer à échanger des messages.
Figure 5 : Address Space (Source OPC UAcademic)
L’espace d’adresses définit comment est organisée une application OPC UA. C’est ici que se
trouvent les variables par exemple. Chaque élément de l’espace d’adresse est un nœud, qui peut
être une des 8 classes présentées sur la figure 5 ci-dessus et définies comme suit :
• Object : Utilisé pour représenter des systèmes, des composants, des objets réels, etc. Les
objets sont liés entre eux par des références ;
• ObjectType : Définition pour les objets ;
• ReferenceType : Définition pour les références ;
• Variable : Stocke des données pour un objet ;
• VariableType : Définition pour les variables ;
• DataType : Type pour les données ;
• Method : Fonction ;
• View : Définit un sous ensemble de l’espace d’adresses. La vue par défaut est l’espace
d’adresses en entier.
Un exemple d’espace d’adresses simple est proposé sur la figure 6. La racine de l’espace d’adresse
est l’URL du serveur. On a ensuite (à la fin de la liste ici) un objet présentant les informations
relatives au serveur (mode de communication, type de sécurité, etc.) puis les objets liés au process,
avec des valeurs associées. L’espace d’adresses se construit à partir de l’installation réelle, en
encapsulant les variables dans des objets. On peut ensuite encapsuler les objets dans d’autres
objets plus grands. Les View permettent ensuite de sélectionner une partie de l’arborescence.
5
Figure 6 : Espace d’adresse de l’application château d’eau
2.5 - Modes de communication
Il existe deux modes de communication entre les applications. Les deux formes peuvent être
adoptées et vont dépendre des cas d’utilisation. Dans les deux types de communication, les
variables sont horodatées. La figure 7 présente les deux modes de communication.
Client/Server : Ce mode de communication est établi entre un client et un serveur. Lors de
l’ouverture de la session, le serveur met en place un abonnement du client sur les variables qui
l’intéressent. La session restant ouverte, le client n’est notifié que lorsque les valeurs ont changé.
Le temps de rafraîchissement des valeurs côté serveur est réglable.
Publication/Subscription : Ce mode de communication met en relation un éditeur et des abonnés.
Les applications n’échangent pas les messages directement, mais passent par un intermédiaire. Les
Publishers envoient leurs données à l’intermédiaire sans savoir s’il y a des abonnés. De leur côté,
les abonnés signalent à l’intermédiaire qu’ils sont intéressés par une donnée, sans savoir si la
donnée est encore mise à jour. Lorsqu’une donnée est modifiée (et uniquement lorsqu’elle est
modifiée), les abonnés sont notifiés du changement et peuvent récupérer la donnée à jour. Cela
permet à plusieurs clients de s’abonner aux mêmes données sans ouvrir de session supplémentaire.
Figure 7 : Modes de communication (source Partie 1 6.6)