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 Server OPC UA); i due condividono l'identità applicativa della stazione ma decidono di chi fidarsi in modo indipendente.

Dispositivo

Preparare il server

La maggior parte dei server OPC UA respinge di fabbrica un client nuovo, per due impostazioni proprie, entrambe fatte sul server:

Dove i server più comuni si fidano del certificato di un client:

Quando il server respinge per l'uno o l'altro motivo, la pagina del dispositivo dice quale in un avviso che prende il posto dello stato del server. Per il certificato ne dà il nome e l'impronta (SHA-1, quella con cui i server lo elencano), ciascuno con un pulsante per copiarlo, e il file con un pulsante che ne apre la cartella. Per l'utente dice se il server non accetta sessioni anonime o se ha rifiutato l'utente, e rimanda a Nome utente e Password di accesso del dispositivo. L'avviso scompare da solo appena si apre una sessione, e il registro e l'agente leggono la stessa indicazione. Questa stazione emette un nuovo certificato quando cambiano il suo nome di applicazione o il suo nome di rete, e il server deve allora fidarsi di quello nuovo.

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: Preparare il server dice dove.

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 è stata 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 nella scheda Accesso delle apparecchiature di questa pagina, la metà in uscita della fiducia sui certificati: un certificato registrato sta sotto In attesa di approvazione finché non lo Approva (le sessioni nuove si possono aprire) o non lo Blocca (rifiutato senza sollevare richieste ripetute). Questo è l'elenco delle apparecchiature; Accesso dei client, nel pannello del Server OPC UA, è 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 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 giudizio 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.

Anche la marca temporale del server viaggia con il campione: il SourceTimestamp che ha dato a un valore buono diventa la Marca temporale dell'origine del tag nella pagina del tag. Un server può tenere quella marca finché il valore o la sua qualità non cambiano, così un valore stabile può mostrare una marca precedente alla Marca temporale dell'applicazione, che è sempre l'istante in cui la stazione ha ricevuto la lettura.

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 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 non sono disponibili come tipo di un tag su questo driver: SByte, le larghezze senza segno diverse da Byte (UInt16, UInt32, UInt64), DateTime, Guid e ByteString.

Un tag di tipo diverso da quello del nodo viene convertito tramite il suo numero, mai riletto attraverso i suoi byte, e la stessa regola vale in lettura e in scrittura. Un reale va in un reale (Float e Double), e un intero in un intero di un'altra larghezza quando il valore ci sta; un tag Boolean su un nodo intero legge 0 e 1 come spento e acceso e li scrive come 0 e 1. Un valore che non ci sta, o un nodo che contiene un altro genere di valore (un reale per un tag intero, un numero per un tag di testo), viene rifiutato su quel solo punto, e una scrittura rifiutata così non viene mai inviata al server.

Una scansione di un server offre quindi meno canali di quanti il server ne tenga: un nodo che dichiara un elenco di valori o che ne contiene uno quando la scansione lo legge, e un nodo il cui tipo è fuori dall'insieme offerto, restano fuori. Molti server lasciano aperta la forma dichiarata di una variabile (un ValueRank Any o ScalarOrOneDimension) anche quando non contiene mai più di un valore; un nodo così viene quindi giudicato dal valore che contiene quando la scansione lo legge, e viene offerto a meno che quel valore non sia un elenco. Se più avanti contiene un elenco, quel solo tag fallisce sulle proprie letture, come per qualunque valore che un tag non può contenere, e gli altri tag del dispositivo continuano a leggere. Il tipo di un nodo è il tipo di base da cui deriva il tipo che dichiara: un nodo dichiarato come VersionTime contiene un UInt32 e uno dichiarato come UtcTime un DateTime, quindi restano fuori entrambi, mentre uno dichiarato come Duration contiene un Double e viene offerto. I server che lasciano aperta la forma spesso lasciano aperto anche il tipo dichiarato (BaseDataType, oppure Number, Integer o UInteger, tipi con cui nessun valore viaggia); un nodo così prende quindi il tipo del valore che contiene quando la scansione lo legge, e viene offerto o resta fuori in base a quel tipo. Un nodo così la cui lettura non riporta alcun valore non mostra alcun tipo e resta fuori. Se più avanti il server invia un valore di un altro tipo, quel valore viene letto secondo la regola di conversione qui sopra, e quel tag fallisce soltanto dove la regola lo rifiuta. 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.

Resta fuori anche, senza essere contato, un nodo a cui il server risponde senza alcun valore: non contiene nulla, e importato non leggerebbe mai. Un nodo il cui valore torna Bad viene invece offerto, a meno che non dichiari un elenco, o non dichiari un tipo aperto senza riportare alcun valore da cui ricavarlo: quello stato dice soltanto che la sua sorgente non ha ancora risposto, o che la sessione anonima della scansione non può leggerlo, e il dispositivo accede con le proprie credenziali.

Scritture

Un tag scrivibile scrive l'attributo Value del nodo attraverso il servizio Write di OPC UA. La risposta del server è il giudizio: 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, tranne i nodi che Tipi di valore lascia fuori. Le aree di diagnostica del server vengono saltate.

Un tag candidato prende il nome del proprio nodo (il suo BrowseName), preceduto da tanti nomi dei nodi sopra di lui quanti bastano a distinguerlo dagli altri canali che il server offre, e non di più: Level invece di Devices.Simulated.Tank.Level sul server di un'altra stazione, e Line1.Speed accanto a Line2.Speed solo dove due nodi chiamati Speed si incontrerebbero. Due nomi che si leggerebbero ancora uguali, diversi solo per maiuscole e minuscole o per la punteggiatura, vengono distinti da un numero. Il percorso completo resta sulla scheda del candidato, su una seconda riga sotto il nome, così sai quale nodo legge ogni tag. Il tag legge il suo ID nodo, quindi il nome è solo come si chiama: nella griglia dei tag e alla fine del suo indirizzo (Connector.OpcUa.Peer.Level).

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.

Un server che c'è già legge altri suoi nodi dalla pagina del suo dispositivo: Rileva tag, nell'intestazione della scheda dei tag, percorre l'endpoint di quel dispositivo accedendo come accede la sessione stessa del dispositivo, con il suo nome utente, la sua password e la sicurezza della sua sessione, così anche un server che rifiuta le sessioni anonime vi mostra i suoi nodi. Offre solo i nodi che nessun tag del dispositivo legge ancora, confrontati attraverso la tabella degli spazi dei nomi del server: un tag scritto con l'indice del suo spazio dei nomi (ns=2;s=Level) legge il nodo che il percorso nomina con l'URI del suo spazio dei nomi (nsu=…;s=Level), quindi quel nodo non viene offerto di nuovo. Un server che rifiuta la sessione chiude la scansione con la causa che dà la sessione stessa del dispositivo (vedere Rilevare i tag di un dispositivo).

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.

Accesso delle apparecchiature

La pagina del driver OPC UA termina con la sua scheda Accesso delle apparecchiature: la metà uscente dell'attendibilità dei certificati. Quando il Connector chiama un server OPC UA di apparecchiatura, quel server dimostra la propria identità con un certificato, e la stazione non legge nulla da un'apparecchiatura il cui certificato non è stato approvato. La testa della scheda lo dice: "Quando il Connector chiama un server OPC UA di apparecchiatura, quel server dimostra la propria identità con un certificato. Approvare solo un'impronta verificata con chi ha messo in servizio l'apparecchiatura." Visualizzare Connector legge la scheda; Configurare Connector decide, e le decisioni si prendono sul desktop proprio della stazione.

Il principio sotto la testa: "Da un'apparecchiatura non approvata non viene letto nulla. Un dispositivo il cui certificato è in attesa qui resta muto e lo dichiara nel Connector. Approvandolo inizia la lettura; ritirando l'approvazione la sessione si chiude e la domanda viene posta di nuovo. I nomi dei certificati sono dichiarati dall'apparecchiatura; l'impronta SHA-256 è l'identità da verificare."

La scheda ha deliberatamente la stessa forma di Accesso dei client, con le stesse parole ovunque l'idea sia la stessa, e la stessa regola su chi può decidere: un browser su un altro dispositivo vede "L'accesso delle apparecchiature può essere cambiato solo nell'applicazione desktop della stazione." e l'avviso "Aprire l'applicazione desktop per cambiare l'accesso delle apparecchiature"; a un ruolo senza Configurare Connector i pulsanti non vengono disegnati, e un'unità in prova e una modifica già in corso rifiutano ciascuna con la propria frase. Ogni esito arriva nella barra di stato.

Che cosa fa nel Connector un dispositivo in attesa

La prima volta che il Connector chiama un dispositivo OPC UA, il certificato dell'apparecchiatura viene rifiutato, registrato qui come in attesa, e il dispositivo non legge nulla. Nella pagina del dispositivo il Connector mostra un avviso di attenzione, In attesa dell'approvazione del certificato, con un pulsante Verifica il certificato che apre questa sezione sulla riga di quel dispositivo, e lo stato di salute del dispositivo nomina lo stesso stato nell'albero. Il fallimento proprio del driver dice il motivo invece di un errore di handshake senza nome: "Il certificato di questa apparecchiatura (i primi 16 caratteri dell'impronta) attende la vostra approvazione in Accesso delle apparecchiature, nella pagina del driver OPC UA. La lettura inizia appena lo approvate." Uno bloccato legge "…è bloccato presso questa stazione. Verificarlo in Accesso delle apparecchiature, nella pagina del driver OPC UA." Anche l'esplorazione del rilevamento passa dallo stesso controllo prima che la sua sessione si apra.

Una volta approvato, il Connector inizia a leggere al tentativo successivo. Un'apparecchiatura che stava leggendo e che comincia a presentare un certificato diverso allo stesso indirizzo smette di essere letta e solleva una scheda persistente, "Certificato cambiato: <nome>": "L'apparecchiatura all'indirizzo <indirizzo> leggeva con un certificato approvato da questa stazione e ora ne presenta uno diverso (…), quindi non viene letto nulla da essa. Verificare l'impronta con chi gestisce l'apparecchiatura, poi approvarla.", con Verifica, più una notifica di Windows per una finestra nascosta. Un dispositivo che si sta registrando in questo momento non viene annunciato così: chi lo registra sta già guardando il Connector.

In attesa di approvazione

Disegnata mentre almeno un certificato aspetta, intestata "Questi dispositivi non vengono letti fino alla decisione." con il conteggio. Ogni riga mostra un punto ambra, il nome che il certificato dichiara, "Identità dichiarata dall'apparecchiatura", l'impronta, "<indirizzo> · Ultimo tentativo <data e ora> · N tentativi di connessione", e una scheda a scomparsa Dettagli del certificato con Soggetto, Emittente, URI dell'applicazione, Nomi di dominio, Valido da, Valido fino al e Visto la prima volta. La riga a cui ha portato un pulsante Verifica è segnata "Selezionato per la verifica" e portata in vista scorrendo.

L'elenco tiene al massimo 100 certificati. Mentre è pieno, un ulteriore certificato resta rifiutato ma non viene conservato, e la scheda lo dice: "L'elenco di verifica qui sotto è pieno. Finché lo è, un nuovo certificato viene rifiutato senza essere aggiunto qui, quindi l'apparecchiatura attesa potrebbe non comparire mai. Scartare i certificati in attesa di verifica per fare spazio.", con il conteggio dei rifiuti da quando si è riempito, una volta che ce ne sono. Ogni rifiuto del genere viene annotato nel diario tecnico.

Apparecchiature approvate

"Certificati con cui il Connector può aprire sessioni.", con il conteggio. Ogni riga mostra un punto neutro, il nome dichiarato, "Identità dichiarata dall'apparecchiatura · Approvato da <utente> il <data e ora>" (oppure "presso questa stazione"), l'impronta e una scheda a scomparsa di dettagli con Indirizzo, Soggetto, Emittente, URI dell'applicazione, Valido fino al e Visto l'ultima volta. Con nessuna: "Nessun certificato di apparecchiatura approvato."

Il suggerimento sotto la testa: "Il certificato pubblico dell'apparecchiatura è già disponibile? Importarlo qui per approvarlo prima della prima connessione, invece di lasciar fallire una volta la connessione. Confrontare l'impronta che aggiunge con quella riportata nella documentazione dell'apparecchiatura." Un'apparecchiatura arriva di solito con il proprio certificato, ed è per questo che su questo lato l'importazione viene prima. Importare un certificato bloccato toglie il blocco. Ritirare l'approvazione rimanda il certificato alla verifica, non a un blocco: si è chiesto di essere interrogati di nuovo.

Apparecchiature bloccate

Una scheda a scomparsa chiusa, "Apparecchiature bloccate" con il conteggio, disegnata soltanto mentre ne esiste almeno una. Ogni riga mostra un punto rosso, il nome dichiarato, "Identità dichiarata dall'apparecchiatura · Bloccato da <utente> il <data e ora>", l'impronta e Sblocca, che la riporta nell'elenco di verifica senza approvarla: "<nome> è sbloccato ed è tornato nell'elenco di verifica." Un certificato bloccato non torna mai da solo.

Dove vivono le decisioni

Gli archivi delle apparecchiature stanno sotto ua\pki\southbound nella radice dei dati della stazione (pending, trusted, blocked e il rejected dell'SDK), con l'indirizzo a cui ogni certificato è stato visto, i conteggi dei tentativi e le decisioni in equipment-access.json. Sono separati dagli archivi in entrata, così un certificato di apparecchiatura non può mai diventare il permesso per un'applicazione di connettersi al server proprio della stazione, né comparire come richiesta in entrata. Non fanno parte di un backup della configurazione.

Ciò che questa sezione non fa

Non viene approvato nulla automaticamente, e nessuna impostazione disattiva questa regola. La scheda non configura il dispositivo in sé (indirizzo, credenziali e interrogazione ciclica stanno nel Connector), non mostra i valori dal vivo dell'apparecchiatura e non decide sulle applicazioni che chiamano questa stazione, che sono in Accesso dei client.