OPC UA

Un client OPC UA per server di terze parti, con fiducia governata dai certificati, indirizzamento per id di nodo e rilevamento dello spazio degli indirizzi.

Il driver OPC UA è un client per server OPC UA di terze parti (PLC, gateway, archivi storici, altri sistemi SCADA) su opc.tcp. È la controparte in uscita del server OPC UA integrato che pubblica lo spazio degli indirizzi di questa stazione (descritto in Impostazioni); i due condividono l'identità applicativa della stazione ma decidono di chi fidarsi in modo indipendente.

Dispositivo

Sicurezza e certificati

La connessione parte dall'elenco di endpoint del server: il client sceglie l'endpoint più sicuro che il server annuncia e autentica l'applicazione con il certificato proprio di questa stazione, la stessa identità applicativa OPC UA che usa il server integrato. Molti server pretendono che quel certificato sia considerato attendibile dalla loro parte prima di accettare la sessione; quel passo si compie sull'apparecchiatura.

Un'apparecchiatura che non annuncia nulla di meglio di un endpoint senza sicurezza viene rifiutata, e il dispositivo dice perché. Quella sessione porterebbe le letture e le credenziali in chiaro e non dimostrerebbe l'identità dell'apparecchiatura, quindi si apre solo dove l'hai chiesta su quel dispositivo: Sicurezza della sessione, Consenti una sessione senza sicurezza, nella scheda di connessione. La scelta appartiene a quel dispositivo, viaggia nel suo indirizzo come ?security=none e vale sia per la sessione di lettura sia per il percorso della ricerca. Attivarla non declassa mai un'apparecchiatura che la sicurezza la offre: viene preso comunque l'endpoint più sicuro annunciato.

Nell'altra direzione la fiducia è esplicita e chiusa in caso di dubbio. Il certificato dell'apparecchiatura viene controllato prima che la sessione si apra:

• Un certificato che questa stazione non ha mai approvato viene rifiutato, registrato per la verifica, e il pannello del dispositivo mostra una nota che nomina l'approvazione che sta aspettando: il dispositivo non è « non connesso », sta aspettando una decisione.
• I certificati si verificano in Impostazioni → Accesso delle apparecchiature, la metà in uscita della fiducia sui certificati: un certificato registrato sta sotto In attesa di approvazione finché non lo Approvi (le sessioni nuove si possono aprire) o non lo Blocchi (rifiutato senza sollevare richieste ripetute). Questo è l'elenco delle apparecchiature; Accesso dei client, sulla stessa pagina, è l'altra direzione, cioè chi può connettersi in entrata al server proprio di questa stazione.
• Ritira l'approvazione, su una riga approvata, chiude le sessioni vive che girano su quel certificato e lo riporta nell'elenco di verifica, così la connessione successiva te lo chiede di nuovo.
• Un'apparecchiatura che non presenta alcun certificato non dimostra nulla su chi ha risposto, quindi non c'è nulla da approvare e la sessione viene rifiutata, con il suo indirizzo scritto nel diario. Si connette solo sotto lo stesso Consenti una sessione senza sicurezza, che a quel punto fa le veci dell'approvazione.

Approvare il server di un'apparecchiatura non autorizza mai quel certificato a connettersi in entrata al server proprio di questa stazione: le due direzioni tengono archivi separati di proposito.

Il comportamento della sessione

I tag vengono interrogati: ogni lettura chiede al server il valore attuale del nodo. Il verdetto del server viaggia con ogni campione: un valore marcato Bad o Uncertain viene rifiutato e il tag legge cattiva qualità, così una sorgente dubbia non viene mai ripulita e spacciata per una lettura buona. Un nodo che sul server non esiste più si legge come nessun valore, invece di far fallire tutto il dispositivo.

La sessione è sorvegliata con i keep-alive; dopo tre keep-alive mancati il client avvia una riconnessione automatica e prosegue. La connessione iniziale appartiene al ciclo di ritentativi in secondo piano dell'applicazione, quindi un server irraggiungibile non costa nulla all'avvio.

Indirizzamento dei tag

Un tag viene indirizzato dal suo Id di nodo, scritto a testo libero e inviato tale e quale. Le forme accettate sono le notazioni standard di OPC UA:

Il tag legge e scrive l'attributo Value del nodo.

Tipi di valore

I valori sono soltanto scalari: gli array, le strutture e gli altri valori complessi vengono rifiutati come illeggibili invece di essere appiattiti in un numero fuorviante, e il tag legge cattiva qualità. Un tag così fallisce da solo; gli altri tag del dispositivo continuano a leggere, e per lui non viene riconnesso nulla. Una stringa vuota è un valore, non un fallimento. I tipi fuori dall'insieme offerto (le larghezze senza segno, DateTime, Guid, ByteString) non sono disponibili su questo driver.

Una scansione di un server offre quindi meno canali di quanti il server ne tenga: un nodo che dichiara un elenco di valori, e un nodo il cui tipo è fuori dall'insieme offerto, restano fuori. Non vengono però lasciati cadere in silenzio. La scansione li conta e il suo messaggio di chiusura dice quanti sono e di che genere, per esempio « 5 canali sono stati lasciati fuori: 3 di tipo UInt32, 2 che contengono un elenco di valori invece di un valore solo. », così un elenco corto si legge come un elenco corto e non come un controllore spoglio.

Scritture

Un tag scrivibile scrive l'attributo Value del nodo attraverso il servizio Write di OPC UA. La risposta del server è il verdetto: una scrittura rifiutata affiora come un fallimento, e il valore in cache avanza solo quando viene accettata. Come dappertutto, il campo di scrittura prende il valore ingegneristico e la catena di conversione viene percorsa all'indietro prima che il valore grezzo parta.

Rilevamento

Il comando Rileva prende un bersaglio nel campo accanto: un indirizzo di server OPC UA come opc.tcp://plc-host:4840. La scansione ha due fasi, e la riga di avanzamento nomina quella in corso:

1. Endpoint: viene interrogato il servizio di rilevamento standard del bersaglio e ogni URL di rilevamento annunciato diventa un endpoint candidato. Le porte e i percorsi di server personalizzati tornano dentro i campi di connessione del candidato.
2. Canali: lo spazio degli indirizzi di ogni candidato viene percorso a partire dalla cartella Objects, e ogni variabile leggibile viene elencata come tag candidato, con il suo tipo e il suo accesso. Le aree di diagnostica del server vengono saltate.

Il percorso accede in modo anonimo (con la stessa scelta dell'endpoint più sicuro, lo stesso rifiuto di una sessione senza sicurezza e lo stesso controllo sul certificato dell'apparecchiatura). Un server che rifiuta le sessioni anonime, un server che non annuncia alcun endpoint sicuro, o un percorso che fallisce per un qualunque motivo, lascia comunque l'endpoint aggiungibile con zero tag: aggiungilo, imposta le credenziali e la sicurezza della sessione sul dispositivo e configura i tag a mano. Nulla viene reso durevole finché non Aggiungi un candidato, e l'annullamento conserva i candidati già completi.

Limiti da conoscere

• Le letture sono interrogazioni dell'attributo Value; il driver non crea sottoscrizioni sul server remoto.
• Soltanto valori scalari: un tag non può indirizzare un elemento di array o un campo di struttura.
• Il controllo di approvazione vale per ogni certificato: un'apparecchiatura che ruota il proprio certificato torna nell'elenco di verifica e aspetta una nuova decisione.