fr Architecture

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

Architecture

Ce chapitre donne à un nouveau développeur un modèle mental rapide du programme : les principaux modules, la manière dont l’interface atteint le backend, les frontières de threads et de processus, et la façon dont les données et les commandes circulent. Chaque classe nommée renvoie à sa page dans la OpcUaManager API Reference.

Cibles de compilation

L’application est construite à partir de trois bibliothèques statiques, deux exécutables et deux modules QML (voir Structure du projet) :

• OpcUaCore — le cœur du client OPC UA, les modèles d’éléments, la persistance et la couche de projet client. Lie Qt Core, Network, OpcUa et Sql.
• ServerProjectCore — le modèle de domaine du projet serveur (.uaserver), le sérialiseur, le validateur et les E/S NodeSet2. Lie Qt Core uniquement afin que le runtime headless puisse le réutiliser sans la pile client.
• OpcUaQmlApi — les façades orientées QML. Dépend d’OpcUaCore et de ServerProjectCore.
• appOpcUaManager — l’exécutable de l’interface (app/).
• OpcUaServerRuntime — l’exécutable serveur open62541 headless (runtime/).
• les modules QML OpcUaManager (écrans) et Base (contrôles réutilisables).

La frontière QML/C++

Le backend C++ est exposé à QML via des propriétés de contexte, et non via des types QML enregistrés. Le moteur de l’application les définit sur le contexte racine :

• cppManagerOpcUa → OpcUaManager (opérations client et modèles)
• cppServerStudio → ServerStudio (conception du serveur et contrôle du runtime)
• cppProjectManager → la façade du projet client
• cppAppEngine → AppEngine (services de l’application)
• cppAppInfo → AppInfo, cppLocale → LocaleController, cppLicenseModel → LicenseModel, cppUpdate → UpdateController

Comme les propriétés de contexte ne nécessitent aucun import, les composants réutilisables Base restent exempts de tout import C++ ; seule la couche applicative les lie aux façades. Il n’y a délibérément aucun module QML Cpp.* dans ce code source.

Client OPC UA : thread de l’interface et thread de travail

Le client est réparti sur deux threads pour garder l’interface réactive :

• OpcUaManager s’exécute sur le thread de l’interface. Il possède les modèles (OpcUaModel, DataAccessModel, AttributesModel, TrendModel) et est le seul objet auquel QML parle.
• OpcUaService s’exécute sur un thread de travail dédié créé par AppEngine. Il possède le QOpcUaClient et effectue la découverte, la connexion/déconnexion, la navigation, les lectures, les écritures et les abonnements.

Les deux communiquent par des signaux mis en file d’attente, de sorte que le travail réseau et PKI ne bloque jamais le rendu. Le décodage des valeurs structurées (de type CODESYS) est assuré par un utilitaire qui parcourt le sous-arbre d’instance.

Serveur OPC UA : deux processus

Le serveur conçu s’exécute en tant que processus séparé, et non à l’intérieur de l’interface :

• ServerStudio (interface) possède le projet serveur en mémoire et les modèles d’édition, et pilote le runtime.
• ServerRuntimeController possède un QProcess exécutant OpcUaServerRuntime. Le runtime intègre open62541, construit l’espace d’adressage à partir du projet, applique la sécurité, simule les valeurs et exécute des règles de comportement.
• Les deux communiquent selon un contrat simple : le runtime imprime une ligne READY avec son point de terminaison sur stdout et accepte STOP sur stdin. Un canal latéral de diagnostics QLocalSocket distinct diffuse en continu le JSON de session/durée de fonctionnement en direct.

Open in Client connecte le client intégré au serveur local en cours d’exécution en transmettant son URL de découverte à OpcUaManager.

Flux de données et de commandes (lecture client)

1. QML appelle une méthode sur cppManagerOpcUa (OpcUaManager).
2. OpcUaManager transmet la requête à OpcUaService via un signal mis en file d’attente.
3. OpcUaService effectue l’appel OPC UA sur le thread de travail.
4. Le résultat revient sous forme de signal mis en file d’attente ; OpcUaManager met à jour le modèle concerné (OpcUaModel / DataAccessModel), auquel QML est lié.

Configuration et stockage

• AppPaths décide des emplacements installé/portable et initialise le stockage inscriptible lors de la première exécution.
• Les réglages résident dans un magasin INI ; les projets client (.uaproj) et les projets serveur (.uaserver) sont en JSON, écrits de façon atomique par leurs sérialiseurs.
• Les nœuds surveillés sont conservés dans une base de données SQLite (NodeDatabase).
• LocaleController installe et change en direct la langue de l’interface.