English · Deutsch · Français · Italiano · Русский · Українська

Serveur OPC UA

Server Studio vous permet de concevoir un serveur OPC UA, de l’exécuter localement, de le sécuriser et de simuler des valeurs — sans écrire de code. Le serveur conçu s’exécute en tant que processus séparé (le runtime headless OpcUaServerRuntime, qui intègre open62541), piloté par l’interface via ServerStudio et ServerRuntimeController (voir Architecture).

Projets serveur

Un projet serveur (.uaserver) est un fichier JSON contenant tout ce dont le runtime a besoin : les espaces de noms personnalisés, les nœuds de l’espace d’adressage, les éventuels types de données d’énumération personnalisés, la configuration du point de terminaison, les paramètres de sécurité et les règles de comportement (ServerProject::ProjectData). Les projets sont créés, ouverts, enregistrés et fermés depuis Server Studio.

Concevoir l’espace d’adressage

Dans le studio, vous construisez un arbre de nœuds (ServerNodeModel) :

• des Objets pour organiser l’espace d’adressage ;
• des Variables avec un type de données et une valeur initiale ;
• des types de données d’énumération personnalisés, référencés par des variables ;
• des espaces de noms personnalisés qui possèdent vos nœuds.

Un espace d’adressage peut aussi être importé plutôt que dessiné à la main :

• Import/export NodeSet2 — échanger le modèle sous forme de XML NodeSet2 OPC UA standard (ServerProject::NodeSet).
• Cloner depuis un serveur parcouru — capturer l’espace d’adressage d’un serveur auquel vous êtes connecté dans le client vers un nouveau projet serveur.

Le projet est vérifié par un validateur avant d’être construit ou démarré (ServerProject::Validator).

Point de terminaison et sécurité

La configuration du point de terminaison définit le port et le nom de l’application. La configuration de sécurité sélectionne la politique de sécurité et les identités acceptées :

• Aucune sécurité pour des tests locaux rapides ;
• Basic256Sha256 avec signature et chiffrement, à l’aide d’un certificat serveur auto-signé créé dans le magasin PKI propre au serveur ;
• accès anonyme et/ou utilisateurs par nom d’utilisateur/mot de passe.

Ces réglages vous permettent d’exercer un client face à une sécurité réaliste sans serveur externe.

Exécuter le serveur

Le démarrage du serveur lance le processus runtime ; le studio attend qu’il signale son point de terminaison, puis l’affiche comme en cours d’exécution. Des diagnostics en direct — nombre de sessions, canaux sécurisés et durée de fonctionnement — sont renvoyés en continu au studio via un canal latéral local (DiagnosticsServer). Vous pouvez arrêter, redémarrer ou forcer l’arrêt du runtime ; le contrôleur signale les plantages et permet de se reconnecter.

Simuler des valeurs

Les variables peuvent recevoir une simulation afin que leurs valeurs changent au fil du temps pendant l’exécution du serveur — compteur, bascule, aléatoire, sinusoïde ou rampe (SimulationEngine). Le runtime écrit les valeurs simulées dans le serveur, de sorte que les clients connectés reçoivent de vraies notifications de changement de données, ce qui est utile pour tester les tendances et les abonnements.

Réagir aux écritures (règles de comportement)

Une variable peut recevoir des règles de comportement : lorsqu’un client écrit la variable, le runtime exécute une ou plusieurs actions sur d’autres variables. Une action écrit soit une valeur fixe, soit la valeur qui vient d’être écrite, éventuellement après un délai. Cela reproduit les échanges requête/réponse qu’une IHM attend d’un automate — par exemple, écrire PageRequest amène le serveur à définir PageResponse —, ce qu’un instantané statique de l’espace d’adressage ne peut pas faire. Les règles sont stockées dans le projet et évaluées par le runtime via des rappels d’écriture OPC UA (RuleEngine).