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

Server OPC UA

Server Studio consente di progettare un server OPC UA, eseguirlo localmente, proteggerlo e simulare valori — senza scrivere codice. Il server progettato viene eseguito come processo separato (il runtime headless OpcUaServerRuntime, che integra open62541), controllato dall’interfaccia tramite ServerStudio e ServerRuntimeController (vedi Architettura).

Progetti server

Un progetto server (.uaserver) è un file JSON che contiene tutto ciò di cui il runtime ha bisogno: gli spazi dei nomi personalizzati, i nodi dello spazio degli indirizzi, gli eventuali tipi di dati di enumerazione personalizzati, la configurazione dell’endpoint, le impostazioni di sicurezza e le regole di comportamento (ServerProject::ProjectData). I progetti vengono creati, aperti, salvati e chiusi da Server Studio.

Progettare lo spazio degli indirizzi

Nello studio si costruisce un albero di nodi (ServerNodeModel):

• Oggetti per organizzare lo spazio degli indirizzi;
• Variabili con un tipo di dati e un valore iniziale;
• tipi di dati di enumerazione personalizzati, referenziati dalle variabili;
• spazi dei nomi personalizzati che possiedono i tuoi nodi.

Uno spazio degli indirizzi può anche essere importato anziché disegnato a mano:

• Import/export NodeSet2 — scambiare il modello come XML NodeSet2 OPC UA standard (ServerProject::NodeSet).
• Clonare da un server esplorato — catturare lo spazio degli indirizzi di un server a cui sei connesso nel client in un nuovo progetto server.

Il progetto viene verificato da un validatore prima di essere costruito o avviato (ServerProject::Validator).

Endpoint e sicurezza

La configurazione dell’endpoint imposta la porta e il nome dell’applicazione. La configurazione di sicurezza seleziona la politica di sicurezza e le identità accettate:

• Nessuna sicurezza per test locali rapidi;
• Basic256Sha256 con firma e cifratura, usando un certificato server autofirmato creato nell’archivio PKI proprio del server;
• accesso anonimo e/o utenti tramite nome utente/password.

Queste impostazioni consentono di mettere alla prova un client con una sicurezza realistica senza un server esterno.

Eseguire il server

L’avvio del server lancia il processo runtime; lo studio attende che segnali il proprio endpoint e poi lo mostra come in esecuzione. Diagnostiche in tempo reale — numero di sessioni, canali sicuri e tempo di attività — vengono trasmesse in streaming allo studio tramite un canale laterale locale (DiagnosticsServer). Puoi arrestare, riavviare o terminare forzatamente il runtime; il controller segnala gli arresti anomali e consente di riconnettersi.

Simulare valori

Alle variabili può essere assegnata una simulazione affinché i loro valori cambino nel tempo mentre il server è in esecuzione — contatore, commutazione, casuale, sinusoide o rampa (SimulationEngine). Il runtime scrive i valori simulati nel server, così i client connessi ricevono vere notifiche di modifica dei dati, utili per testare tendenze e sottoscrizioni.

Reagire alle scritture (regole di comportamento)

A una variabile possono essere assegnate regole di comportamento: quando un client scrive la variabile, il runtime esegue una o più azioni su altre variabili. Un’azione scrive un valore fisso oppure copia il valore appena scritto, eventualmente dopo un ritardo. Questo riproduce gli handshake richiesta/risposta che un’HMI si aspetta da un PLC — per esempio, scrivere PageRequest fa impostare al server PageResponse —, cosa che un’istantanea statica dello spazio degli indirizzi non può fare. Le regole sono memorizzate nel progetto e valutate dal runtime tramite callback di scrittura OPC UA (RuleEngine).