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

Architettura

Questo capitolo offre a un nuovo sviluppatore un rapido modello mentale del programma: i moduli principali, il modo in cui l’interfaccia raggiunge il backend, i confini di thread e processo e come fluiscono dati e comandi. Ogni classe nominata rimanda alla sua pagina nel OpcUaManager API Reference.

Target di build

L’applicazione è costruita a partire da tre librerie statiche, due eseguibili e due moduli QML (vedi Struttura del progetto):

• OpcUaCore — il nucleo del client OPC UA, i modelli di elementi, la persistenza e il livello del progetto client. Collega Qt Core, Network, OpcUa e Sql.
• ServerProjectCore — il modello di dominio del progetto server (.uaserver), il serializzatore, il validatore e l’I/O NodeSet2. Collega solo Qt Core affinché il runtime headless possa riutilizzarlo senza lo stack client.
• OpcUaQmlApi — le facciate rivolte a QML. Dipende da OpcUaCore e ServerProjectCore.
• appOpcUaManager — l’eseguibile dell’interfaccia (app/).
• OpcUaServerRuntime — l’eseguibile server open62541 headless (runtime/).
• i moduli QML OpcUaManager (schermate) e Base (controlli riutilizzabili).

Il confine QML/C++

Il backend C++ è esposto a QML tramite proprietà di contesto, non tramite tipi QML registrati. Il motore dell’applicazione le imposta sul contesto radice:

• cppManagerOpcUa → OpcUaManager (operazioni client e modelli)
• cppServerStudio → ServerStudio (progettazione del server e controllo del runtime)
• cppProjectManager → la facciata del progetto client
• cppAppEngine → AppEngine (servizi dell’applicazione)
• cppAppInfo → AppInfo, cppLocale → LocaleController, cppLicenseModel → LicenseModel, cppUpdate → UpdateController

Poiché le proprietà di contesto non richiedono alcun import, i componenti riutilizzabili Base restano privi di qualsiasi import C++; solo il livello applicativo li collega alle facciate. In questo codice sorgente non esistono deliberatamente moduli QML Cpp.*.

Client OPC UA: thread dell’interfaccia e thread di lavoro

Il client è suddiviso su due thread per mantenere reattiva l’interfaccia:

• OpcUaManager viene eseguito sul thread dell’interfaccia. Possiede i modelli (OpcUaModel, DataAccessModel, AttributesModel, TrendModel) ed è l’unico oggetto con cui QML dialoga.
• OpcUaService viene eseguito su un thread di lavoro dedicato creato da AppEngine. Possiede il QOpcUaClient ed esegue discovery, connessione/disconnessione, navigazione, letture, scritture e sottoscrizioni.

I due comunicano tramite segnali in coda, così il lavoro rivolto a rete e PKI non blocca mai il rendering. La decodifica dei valori strutturati (in stile CODESYS) è gestita da un helper che esplora il sottoalbero di istanza.

Server OPC UA: due processi

Il server progettato viene eseguito come processo separato, non all’interno dell’interfaccia:

• ServerStudio (interfaccia) possiede il progetto server in memoria e i modelli di editing e pilota il runtime.
• ServerRuntimeController possiede un QProcess che esegue OpcUaServerRuntime. Il runtime integra open62541, costruisce lo spazio degli indirizzi dal progetto, applica la sicurezza, simula i valori ed esegue regole di comportamento.
• I due comunicano tramite un contratto semplice: il runtime stampa una riga READY con il proprio endpoint su stdout e accetta STOP su stdin. Un canale laterale di diagnostica QLocalSocket separato trasmette in streaming il JSON di sessione/tempo di attività in tempo reale.

Open in Client connette il client integrato al server locale in esecuzione passando il suo URL di discovery a OpcUaManager.

Flusso di dati e comandi (lettura client)

1. QML chiama un metodo su cppManagerOpcUa (OpcUaManager).
2. OpcUaManager inoltra la richiesta a OpcUaService tramite un segnale in coda.
3. OpcUaService esegue la chiamata OPC UA sul thread di lavoro.
4. Il risultato torna come segnale in coda; OpcUaManager aggiorna il modello interessato (OpcUaModel / DataAccessModel), a cui QML è collegato.

Configurazione e archiviazione

• AppPaths decide le posizioni installato/portable e inizializza l’archiviazione scrivibile alla prima esecuzione.
• Le impostazioni risiedono in un archivio INI; i progetti client (.uaproj) e i progetti server (.uaserver) sono in JSON, scritti in modo atomico dai loro serializzatori.
• I nodi monitorati sono conservati in un database SQLite (NodeDatabase).
• LocaleController installa e cambia in tempo reale la lingua dell’interfaccia.